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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Chair  of  the  Open  Systems 
Interconnection  Implementors'  Workshop  (OIW). 

This  part  replaces  the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change 
from  this  text  as  previously  given. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  1  -  General  Information 


0  Introduction 

This  document  records  current  stable  implementation  agreements  of  OSI  protocols  among  the  organizations 
participating  in  the  OSI  Implementors'  Worl<shop  (OIW).  Stable  in  the  context  of  this  document  means  the 
following: 

a)  the  agreements  are  based  on  final  standards  (e.g.,  ISO-IS  or  CCITT  Recommendations)  or  nearly 
final  (e.g.,  ISO-DIS)  with  no  significant  changes  expected; 

b)  the  agreements  have  been  approved  by  the  OSI  Implementors'  Workshop  (OIW)  Plenary  for 
progression  from  the  Working  Agreements  document  to  this  document  after  a  period  of  review. 
These  agreements  are  considered  final;  the  only  changes  allowed  will  be  clarifications,  and  certain 
Technical  and  Alignment  errata.  These  changes  must  have  the  strong  support  of  vendors,  and  be 
justifiable. 

For  these  reasons,  the  agreements  are  considered  advanced  enough  for  use  in  product  and  test  suite 
development.  This  means  that  readers  can  use  this  text  as  a  basis  for  procurement  references  for  OSI 
products.  All  of  the  text  in  this  document  is  considered  stable  as  defined  above. 

Future  releases  of  these  Stable  Agreements  will  add  and/or  extend  functionality  offered  by  this  edition  and 
version.  When  required,  new  versions  will  be  introduced  on  a  yearly  basis.  It  is  the  OSI  Implementors' 
Workshop  (OIW)  intent  that  new  versions  of  this  Stable  Agreements  document  will  be  compatible  with  the 
present  version.  If  this  proves  impractical,  the  agreements  will  attempt  to  provide  mechanisms  and 
guidelines  which  maximize  interoperability.  Furthermore,  it  is  the  intent  that  these  stable  agreements  be 
maintained  via  the  Errata  process  as  long  as  is  appropriate.  For  the  subject  area,  intenA/orking  information 
and  other  useful  advice  to  the  reader  is  given  as  appropriate.  Specific  "defect  report"  information  (including 
extent  of  applicability)  is  provided  in  designated  portions  of  each  Part. 


1  Scope 

Agreements  text  is  either  in  this  Stable  Document  (Stable)  or  in  the  aligned  Working  Document  (not  yet 
stable).  It  is  a  goal  that  the  same  text  not  appear  in  the  same  position  in  both  documents  at  once  (except 
for  part  1).  Modifications  to  a  version  reflect  very  recent  stable  functionality  as  well  as  editorial,  technical, 
and  alignment  errata,  all  applied  to  the  previous  edition. 

The  intended  audience  for  this  document  is  composed  of  those  individuals  who  are  interested  in  Stable 
Implementation  Agreements  for  OSI  protocols.  Each  part  of  the  document  covers  a  different  subject  area, 
and  the  parts  are  presented  so  as  to  present  a  consistent  and  unified  approach.  The  format  of  this  version 
follows  the  ISO  directives  whenever  possible. 

The  corresponding  and  aligned  document,  "Working  Implementation  Agreements  for  OSI  Protocols,"  records 
agreements  which  are  not  yet  considered  stable,  in  the  sense  described  above.  This  document  will  be 
referenced  as  the  "Working  Agreements  Document."  This  Stable  document  is  aligned  with  the  Working 
Agreements  Document  in  the  sense  that  the  structures  are  identical,  and  pointers  are  given  in  this  Stable 
Document  to  work  in  the  Working  Agreements  Document  which  could  become  stable  in  the  future. 
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The  benefit  of  this  document  to  the  reader  is  that  it  gives  a  complete  accounting  of  current  stable 
agreements.  Minor  changes  (Errata)  to  these  agreements  will  be  issued  in  replacement  page  format.  These 
errata  will  only  be  applied  to  the  current  version. 

Currently  efforts  are  under  way  to  define  worldwide  technically  harmonized  profiles.  The  goal  is  to  create 
a  consolidated  global  market  for  OS!  products.  This  means  that  vendors  can  sell  to  a  larger  market,  and 
users  can  procure  products  from  a  variety  of  vendors  around  the  world.  Agreements  in  this  document  are 
likely  to  be  used  in  these  alignment  efforts. 

This  version  is  backwards  compatible  with  the  previous  version  to  the  maximum  extent  possible.  This 
version  includes  all  of  the  material  from  the  previous  version  (modified  by  errata)  as  well  as  new  stable 
material  from  the  previous  year;  important  new  functional  additions  are  in  the  areas  of  Network  l_ayer 
routeing,  Network  Management  text,  features  of  1988  based  X.400  agreements,  VTtext,  FTAM  text,  Directory 
Services  text.  Security  text,  and  image  and  raster  document  application  profiles. 


2     Normative  References 

See  succeeding  parts.     .  ., 


3  Definitions 

See  succeeding  parts. 


4     Purpose  of  the  Workshop 

In  February,  1983,  at  the  request  of  industry,  NiST  organized  the  OSI  Implementors'  Workshop  (OIW)  for 
Implementors  of  OSI  to  bring  together  future  users  and  potential  suppliers  of  OSI  protocols.  The  Workshop 
accepts  as  input  the  specifications  of  emerging  standards  for  protocols  and  produces  as  output  agreements 
on  the  implementation  and  testing  particulars  of  these  protocols.  This  process  is  expected  to  expedite  the 
development  of  OSI  protocols  and  promote  interoperability  of  independently  manufactured  data 
communications  equipment. 
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5     Workshop  Organization 

The  Workshop  organizes  its  work  through  Special  Interest  Groups  (SIGs)  that  prepare  technical 
documentation.  An  executive  committee  of  SIG  chairpersons  led  by  the  overall  Workshop  chairperson 
administers  the  Workshop.  NIST  invites  highly  qualified  technical  leaders  from  participating  organizations 
to  assume  leadership  roles  in  the  SIGs.  The  SIGs  are  encouraged  to  coordinate  with  standards 
organizations  and  user  groups,  and  to  seek  widespread  technical  consensus  on  implementation  agreements 
through  international  discussions  and  liaison  activities. 

The  Workshop  meets  four  times  a  year  at  the  National  Institute  of  Standards  and  Technology  in 
Gaithersburg,  Maryland  where  each  SIG  is  required  to  convene  its  meeting.  In  addition,  a  plenary  assembly 
of  all  Workshop  delegates  is  convened  for  consideration  of  SIG  motions  and  other  Workshop  business. 
SIGs  are  also  encouraged  to  hold  interim  meetings  at  varied  locations  around  the  world. 

The  Workshop  is  an  open  public  forum.  Registration  materials,  documents,  and  Workshop  schedules  are 
available  from: 

National  Institute  of  Standards  and  Technology 
OSI  Implementors'  Workshop  (OIW) 
Building  225,  Room  B-217 
Gaithersburg,  Maryland  20899 


6     Use  and  Endorsement  by  other  Enterprises 

The  Workshops  are  held  for  those  organizations  expressing  an  interest  in  implementing  or  procuring  OSI 
Protocols  and  Open  Systems.  However,  there  is  no  corporate  commitment  to  implementations  associated 
with  Workshop  participation. 

The  Workshop  and  associated  agreements  have  been  endorsed  by  various  activities  and  groups.  See  the 
aligned  clause  of  the  Working  Agreements  Document  for  more  on  this  subject. 


7     Relationship  of  the  Workshop  to  the  NIST 

As  resources  permit,  NIST,  with  voluntary  assistance  from  industry,  develops  formal  protocol  specifications, 
reference  implementations,  tests,  and  test  systems  for  the  protocols  agreed  to  in  the  Workshops.  The  NIST 
organizes,  administers,  and  makes  technical  contributions  to  the  Workshop.  The  NIST  bears  no  other 
relation  to  the  workshop. 
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8     Structure  and  Operation  of  Workshop 


8.1  Plenary 

The  main  body  of  the  workshop  is  a  Plenary  Assembly.  Any  organization  may  participate.  Representation 
Is  international.  The  NIST  prefers  for  the  business  of  Workshops  to  be  conducted  informally  since  there  are 
no  corresponding  formal  commitments  within  the  Workshop  to  implement  the  decisions  reached.  For  more 
information,  consult  the  aligned  clause  of  the  Working  Agreements  Document. 


8.2      Special  Interest  Groups 

Within  the  Workshop  there  are  Special  Interest  Groups  (SIGs).  The  SIGs  receive  their  instructions  for  their 
technical  program  of  work  from  the  Plenary.  The  SIGs  meet  independently  during  the  Workshop  week.  As 
technical  work  is  completed  by  a  SIG,  it  is  presented  to  the  Plenary  for  disposition.  For  more  information 
on  SIGs  (including  SIG  charters),  consult  the  aligned  clause  of  the  Working  Agreements  Document. 


9     Points  of  Contact 

For  information  concerning  the  workshop,  write  to: 

Chair,  OSI  Implementors'  Workshop  (OIW),  at  the  address  given  in  1.3. 

Individual  points  of  contact  are  given  in  the  aligned  part  of  the  Working  Agreements  Document. 


10   Profile  Conformance 

NOTE  -  SIG  text  relating  to  text  below  may  be  given  in  some  succeeding  parts. 

This  clause  presents  general  concepts  for  profile  conformance.  These  concepts  shall  be  observed  when 
writing  Implementation  Agreements. 

10.1     General  Principle 

Conformance  to  an  OSI  Profile  (Implementation  Agreements,  Functional  Standards)  implies  conformance 
to  the  referenced  Base  Standards. 

Therefore,  a  Profile  shall  not  specify  any  requirements  that  would  contradict  or  cause  non-conformance  to 
the  Base  Standards  to  which  it  refers  (see  TR  10000-1,  clauses  6.1,  6.3.1).  The  conformance  requirements 
defined  in  ISO/IEC  TR  10000-1  fully  apply. 
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Base  standards  usually  provide  options  for  PDUs,  parameters,  encoding  choices,  value  ranges,  etc. 

A  profile  may  make  specific  choices  of  these  options  and  ranges  of  values.  For  the  promotion  of 
Interoperability,  pragmatic  constraints  or  minimum  requirements  may  be  Imposed  (e.g.,  the  limitation  of 
Search  operations,  selection  of  encoding  choices,  value  ranges,  byte  ranges  for  encoding).  These  minimum 
requirements  of  restrictions  shall  not  contradict  the  conformance  requirements  of  the  respective  base 
standards. 


10.2.1      Sending/Encoding  Entity 

In  order  to  promote  interworking,  reasonable  restrictions  or  minimum  requirements  may  be  specified  in  a 
profile  as  described  above. 


10.2.2      Receiving/Decoding  Entity 

Minimum  requirements  of  receiving/decoding  capability  for  alternatives,  permissible  values,  etc.  may  be 
specified  in  a  profile.  A  profile  shall  not  specify  the  behavior  of  a  receiving/decoding  entity  when  receiving 
data  which  Is  outside  the  scope  of  or  excluded  by  the  Profile  for  senders. 

A  Profile  Conformance  Test  shall  be  limited  by  the  scope  of  the  profile  specification  and  shall  not  probe 
beyond  Its  boundaries.  That  means,  the  capability  of  a  receiver/decoder  would  be  tested  only  In  the  range 
of  choices  or  values  which  are  specified  for  the  sending/encoding  entity  (I.e.,  for  interworking  between 
systems  both  being  conformant  to  the  Profiles). 


10.3    Classification  of  Conformance 

Conformance  requirements  of  a  profile  shall  be  related  to  conformance  requirements  of  a  base  standard  as 
written  In  clause  6.5  and  annnex  C  of  ISO/IEC  TR  10000-1.  For  the  conformance  classes,  the  following 
terminology  shall  be  used  unless  othen/vlse  specified  by  the  base  standard  or  equivalent  conformance 
requirements  for  a  profile  as  required  by  the  ISO/IEC  Technical  Committee  that  is  responsible  for  the  base 


standard: 

a) 

m 

mandatory; 

b) 

0 

optional; 

c) 

c 

conditional; 

d) 

X 

excluded; 

e) 

i 

out  of  scope; 

f) 

not  applicable. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest  Group 
(LLSIG)  of  the  Open  Systems  Interconnection  Implementors'  Workshop  (OIW).  See  Procedures  Manual  for 
Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject. 

Annexes  A  and  B  are  for  information  only. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  2  -  Subnetworks 


0  Introduction 

This  part  provides  agreements  about  subnetwork  services  used  in  support  of  tlie  OSI  Networl<  l_ayer. 


1  Scope 

These  agreements  cover  subnetworl<  types  including  local  area  networks,  packet  switched  networks,  circuit 
switched  networks,  ISDN,  and  others. 


2     Normative  References 


2.1  CCITT 

[1]       Recommendation  1.231  (Blue  Book,  1988),  Circuit-Mode  Bearer  Service  Categories. 

[2]       Recommendation  1.232  (Blue  Book,  1988),  Packet-Mode  Bearer  Service  Categories. 

[3]  Recommendation  1.431  (Blue  Book,  1988),  Primary  Rate  User-Network  Interface  -  Layer  1 
Specification. 

[4]  Recommendation  Q.921  (1.441)  (Blue  Book,  1988),  ISDN  User-Network  Interface,  Data  Link  Layer 
Specification. 

[5]  Recommendation  Q.931  (1.451)  (Blue  Book,  1988),  ISDN  User-Network  Interface  Layer  3 
Specification  for  Basic  Call  Control. 

[6]  Recommendation  X.25  (Yellow  Book  1980),  Interface  Between  Data  Terminal  Equipment  (DTE)  and 
Data  Circuit  Terminating  Equipment  (DCE)  for  Terminals  Operating  in  the  Packet  Mode  on  Public 
Data  Networks. 

[7]  Recommendation  X.25  (Blue  Book,  1988),  Interface  Between  Data  Terminal  Equipment  (DTE)  and 
Data  Circuit-Terminating  Equipment  (DCE)  for  Terminals  Operating  in  the  Packet  Mode  and 
Connected  to  Public  Data  Networks  by  Dedicated  Circuit. 

[8]       Recommendation  X.31  (Blue  Book,  1988),  Support  of  Packet  Mode  Terminal  Equipment  by  an  ISDN. 
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[9]       ISO  7776,  Information  processing  systems  -  Data  communication  -  Higti-level  Data  Link  Control 
Procedures  -  Description  of  the  X.25  LAPB-compatible  DTE  data  link  procedures. 

[10]      ISO/IEC8208  Edition2,  Information  technology -Data  communications -X.25  Packet  layer  protocol 
for  data  terminal  equipment. 

[11]      ISO  8802-2,  Information  processing  systems  -  Local  area  networks  -  Part  2:  Logical  link  control. 

[12]      ISO  DIS  8802-3,  Information  processing  systems  -  Local  area  networks  -  Part  3:  Carrier  sense 
multiple  access  method  with  collision  detection  (CSMA/CD)  and  physical  layer  specifications. 

[13]     I  SO  Dl  S  8802-4,  Information  processing  systems  -  Local  area  networks  -  Part  4:  Token-passing  bus 
access  method  and  physical  layer  specifications. 

[14]      ISO  8802-5,  Information  processing  systems  -  Local  area  networks  -  Part  5:  Token  ring  access 
method  and  physical  layer  specifications. 

[15]      ISO  931 4-1 ,  Information  processing  systems  -  Fibre  distributed  data  interface  (FDDI)  -  Part  1:  Token 
ring  physical  layer  protocol  (PHY). 

[16]      ISO  931 4-2,  Information  processing  systems  -  Fibre  distributed  data  interface  (FDDI)  -  Part  2:  Token 
ring  media  access  control  (MAC). 

[17]      ISO  DIS  9314-3,  Information  processing  systems  -  Fibre  distributed  data  interface  (FDDI)  -  Part  3: 
Physical  layer  medium  dependent  (PMD). 

[18]      ISO  10039,  Information  Technology  -  Local  Area  Networks  -  MAC  Sen/ice  Definition 


2.3  ANSI 

[19]     ANSI/IEEE  802.2,  Logical  Link  Control,  1987. 

[20]     ANSI/I EEE  802.3,  Carrier  Sense  Multiple  Access  with  Collision  Detection  (CSMA/CD)  and  Physical 
Layer  Specifications,  1985. 

[21]     ANSI/IEEE  802.3  Supplement  a,  MAU  and  Baseband  Medium  Specification,  Type  10BASE2  (Section 
10),  1988. 

[22]     ANSI/IEEE  802.3  Supplement  b.  Broadband  MAU  and  Broadband  Medium  Specifications,  Type 
10BROAD36  (Section  11),  1988. 

[23]     ANSI/IEEE  802.3  Supplement  c,  Repeater  Unit  for  10  Mb/s  Baseband  Networks  (Section  9),  1 988. 

[24]     ANSI/IEEE  802.3  Supplement  e.  Physical  Signaling,  Medium  Attachment,  and  Baseband  Medium 
Specifications,  Type  1  BASES  (Section  12),  1988. 
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[25]      ANSI/IEEE  802.4,  Token-Passing  Bus  Access  Method  and  Physical  Layer  Specifications,  Draft 
1987. 

[26]     ANSI/IEEE  802.5,  Token-Ring  Access  Method  and  Physical  Layer  Specifications,  1986. 

[27]     ANS  T1 .408-1 990,  ISDN  Primary  Interface  -  Customer  Installation  Metallic  Interfaces  -  Layer  1 
Specification. 

[28]     ANS  T1.601,  Integrated  Services  Digital  Network  (ISDN)  -  Basic  Access  Interface  for  Use  on 
Metallic  Loops  for  Application  on  the  Network  Side  of  the  NT  (Layer  1  Specification). 

[29]      ANS  T1 .602,  Integrated  Sen/ices  Digital  Network  (ISDN)  -  Data-Link  Layer  Signalling  Specification 
for  Application  at  the  User-Network  Interface. 

[30]     ANS  T1 .605,  Integrated  Services  Digital  Network  (ISDN)  -  Basic  Access  Interface  for  S  and  T 
Reference  Points  -  Layer  1  Specification. 

[31]     ANS  T1.607,  Telecommunications  -  Digital  Subscriber  Signaling  System  #7  -  Layer  3  Signaling 
Specification  for  Circuit  Switched  Bearer  Service. 

[32]      ANS  T1.608,  Telecommunications  -  Digital  Subscriber  Signaling  System  #1  -  Layer  3  Signaling 
Specification  for  Packet  Switched  Bearer  Service. 

[33]     ANS  X3. 1 39,  Fiber  distributed  data  interface  (FDD!)  -  Token  ring  media  access  control  (MAC) ,  1 987. 

[34]     ANS  X3.148,  Fiber  distributed  data  interface  (FDDI)  -  Token  ring  physical  layer  protocol  (PHY),  1988. 

[35]     ANS  X3.166,  Fiber  distributed  data  interface  (FDDI)  -  Physical  layer  medium  dependent  (PMD), 
1989. 


3  Status 

This  version  was  completed  in  December  1 990. 
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NOTE  -  This  clause  may  contain  "defect  report"  and  resolutions  material,  and  the  versions  of  Implementor's 
Agreements  to  which  this  material  applies. 


5     Local  Area  Networks 

5.1      IEEE  802.2  Logical  Link  Control 

The  following  decisions  have  been  reached  with  respect  to  this  protocol: 
,,i      a)  Link  Sen/ice  Access  Point  (LSAP): 

1)  The  code  below  shall  be  used  to  address  systems  using  Network  Layer  protocols 
identified  by  ISO  TR  9577  (e.g.,  ISO  8473,  ISO  8208).  Note  that  bit  zero  is  transmitted  first; 

2)  The  most  significant  bit  is  bit  7,  thus  this  bit  pattern  represents  hexadecimal  FE  (see 
figure  1  below); 

b)  Type  and  Class: 

1)  Only  the  connectionless  type  1,  class  I  IEEE  802  link  service  will  be  used. 


Figure  1  -  LSAP  bit  pattern 


5.2      IEEE  802.3  CSMA/CD  Access  Method 

The  following  implementation  agreements  have  been  reached  with  respect  to  the  IEEE  802.3  CSMA/CD 
Access  Method  and  Physical  Layer  Specifications: 

a)  The  address  length  shall  be  48  bits; 

b)  For  a  data  packet  of  LLC  data  length  of  n  octets,  the  length  of  the  pad  field  is  as  follows: 

1)  max(0,  minFrameSize-(8n  +  2(addressSize)  +  48))  bits. 
The  following  implementation  agreements  have  been  reached  with  respect  to  10  BROAD  36  Networks: 
a)  Single  Cable  Networks: 

1)  The  translator  frequency  shall  be  192.25  Mhz; 
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2)  The  channel  allocations  are  as  follows: 

a)  Reverse  Channels: 

1)  T12,  T13.  T14 

2)  T13.  T14,  2" 

3)  T14.  2'.  3' 

4)  2',  3'.  4' 

5)  3",  4",  4A' 

6)  4".  4A',  5" 

b)  Forward  Channels: 

1)  L,  M,  N 

2)  M.  N,  O 

3)  N,  O,  P 

4)  O,  P,  Q 

5)  P.  Q,  R 

6)  Q,  R,  S 
b)  Dual  Cable  Networks: 

For  nontranslated  dual  cable  networks  fonward  and  reverse  frequencies  are  the  same.  Permissible 
channel  allocations  are  listed  below: 

1)  T12,  T13.  T14 

2)  T13,  T14,  2' 

3)  T14,  2",  3" 

4)  2',  3'.  4- 

5)  3',  4',  4A' 

6)  4'.  4A',  5' 

7)  L,  M,  N 
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8)  M,  N,  0 

9)  N,  O,  P 

10)  O,  P,  Q 

11)  Q,  R.  S 

c)  When  both  IEEE  802.4  and  IEEE  802.3  10  BROAD  36  networks  coexist  on  the  broadband  cable 
system  the  preferred  channel  allocations  are  as  follows: 

^  1)  Reverse: 

a)  T12,  T13,  T14  -  IEEE  802.3; 

b)  6',  FMV  -  IEEE  802.4; 

c)  3',  4'-  Channels  reserved  for  future  use; 

d)  4A',  5'  -  Channels  reserved  for  future  use; 
2)  Forward: 

a)  L,  M.  N  -  IEEE  802.3; 

b)  T.  U  -  IEEE  802.4; 

c)  P,  Q  -  Channels  reserved  for  future  use; 

d)  R,  S  -  Channels  reserved  for  future  use. 

The  following  implementation  agreements  have  been  reached  with  respect  to  10  BASE-T  networks: 

a)  Auto-partition:  A  repeater  port  which  connects  10  BASE-T  links  either  through  an  external  or 
internal  MAD  shall  implement  the  auto-partition  and  reconnections  algorithm  as  defined  in  IEEE 
802.3,  Chapter  9. 

5.3      IEEE  802.4  Token  Bus  Access  Method 

The  following  options  are  agreed  to  with  respect  to  Draft  J  of  token  bus: 

a)  Data  Rate: 

1)  10  Mb  (Broadband); 

2)  5  Mb  (Carrierband); 

b)  Addressing:  48  bit; 
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c)  The  ImeOption,  Priority  Mechanism,  shall  be  implemented; 

d)  Broadband  Channel  Assignments  are  as  follows: 

1)  Forward: 

a)  P 

b)  Q 

c)  R 

d)  S 

e)  T 

f)  U 

2)  Reverse: 

a)  3" 

b)  4' 

c)  4A' 

d)  5' 

e)  6' 

f)  FM1'. 

5.4      IEEE  802.5  Token  Ring  Access  Method 

The  following  implementation  agreements  have  been  reached  with  respect  to  the  IEEE  Standard  802.5, 
Token  Passing  Ring  Access  Method  and  Physical  Layer  specification: 

a)  The  data  signalling  rate  shall  be  4  Mbit/s; 

b)  The  address  length  shall  be  48  bits; 

c)  The  message  priority  (PM)  of  the  AMP  data  unit  shall  be  7; 

d)  The  ALL_STATIONS_THIS_RING_ADDRESS  shall  be  X'COOOFFFFFFFF; 

e)  The  TRR  value  shall  be  4  milliseconds; 

f)  The  THT  value  shall  be  8.9  milliseconds; 
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g)  The  TQP  value  shall  be  20  milliseconds; 

h)  The  TVX  value  shall  be  10  milliseconds; 

i)  The  TNT  value  shall  be  2.6  milliseconds; 
j)  The  TAM  value  shall  be  7  seconds; 

k)  The  TSM  value  shall  be  15  seconds; 

I)  The  MAC  Information  field  (l-field)  shall  be  defined  as  follows  in  figure  2  below.  Sequences  are 
as  follows: 

1)  Starting  Sequence  includes:  SD,  AC,  FC,  DA,  SA; 

2)  Ending  Sequence  includes:  FCS,  ED,  FS; 

m)  With  the  above  timer  and  MAC  l-field  definitions,  the  following  limits  are  defined: 

1)  Protocol  limits  the  l-field  to  a  maximum  of  4425  bytes; 

2)  All  stations  shall  support  l-fields  that  have  a  minimum  of  one  byte  and  a  maximum  of 
at  least  2000  bytes. 


Starting  Sequence 


I-Field 


End  Sequence 


Figure  2  -  I-Field  format 

5.5      Fiber  Distributed  Data  Interface  (FDDI) 

5.5.1        Token  Ring  Media  Access  Control  (MAC,  X3.1 39-1 987) 

The  following  are  implementation  agreements  with  respect  to  FDDI  MAC: 

a)  The  address  length  shall  be  48  bits; 

b)  There  shall  be  some  manual  or  programmatic  means  of  resetting  stations  and  concentrators  to 
the  values  specified  as  defaults  herein  or  in  X3. 139-1 987; 

c)  The  default  value  of  T_Max  shall  be  at  least  165  milliseconds  and  not  more  than  200 
milliseconds; 
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d)  The  default  value  of  T_Req  shall  be  equal  to  either  T_MAX  or  T_Req_Max'  whichever  is  less; 

e)  All  FDDI  stations  shall  process  lnfo_Fields  of  0  to  4478  bytes.  The  frame  is  defined  as  follows 
in  Figure  3: 

f)  Stations  shall  not  use  restricted  token  sen/ice. 


p 

SD 

FC 

DA 

SA 

Info 

FCS 

ED 

FS 

Figure  3  -  FDDI  frame  format 


P:  Preamble 

- 16  Idle  Symbols  for  Transmitting 

-  >  =  6  Idle  Symbols  for  Copying 

-  >  =  2  Idle  Symbols  for  Repeating 
SD:  Starting  Delimiter  (2  Symbols,  JK) 
FC:      Frame  Control  (2  Symbols) 

DA:      Destination  Address  (12  Symbols) 
SA:      Source  Address  (12  Symbols) 
INFO:   Information  Field  (-  <8956  Symbols) 
FCS:     Frame  Check  Sequence  (8  Symbols) 
ED:      Ending  Delimiter  (1  Symbol) 
FS:      Frame  Status  (3  Symbols) 


5.5.2       Token  Ring  Physical  Layer  (PHY,  X3.1 48-1 988) 

The  following  implementation  agreement  is  with  respect  to  the  FDDI  PHY  specifications: 

1  The  average  delay,  that  is  the  time  between  when  a  station  receives  a  Starting  Delimiter  (JK  symbol 
pair)  beginning  a  valid  frame  until  it  repeats  that  Starting  Delimiter,  when  that  Starting  Delimiter  is 
preceded  by  a  sequence  of  a  valid  frame  followed  by  50  Idle  Symbols  shall  not  exceed: 

1  microsecond  in  a  station,  and 

1  microsecond  times  the  number  of  ports  in  a  concentrator,  in  addition  to  the  delays 
contributed  by  the  active  slaves  of  the  concentrator. 

The  measurement  method  described  above  allows  a  consistent  repeatable  measurement,  however 
it  does  not  measure  maximum  possible  delay.  When  the  delay  is  one  microsecond  as  measured 


T_Req_Max  is  defined  in  the  Ring  Management  (RMT)  section  of  Station  Management.  It  is  used 
in  the  resolution  of  duplicate  address  problems  which  prevent  ring  initialization.  Stations  which  have 
detected  that  they  are  duplicates  during  ring  initialization  take  action  to  make  sure  that  they  lose 
the  Claim  process  to  other  stations  having  a  T_Req  value  less  than  T_Req_Max.  T_Req_Max  is 
specified  in  SMT  to  have  a  value  <.  167.8  milliseconds. 
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above,  the  maximum  effective  delay  contribution  component  which  can  result  is  1.164 
microseconds.  This  number,  not  one  microsecond,  should  be  used  per  PHY  to  compute  maximum 
possible  netv^^ork  delay. 


5.5.3       Physical  Layer  Media  Dependent  (PMD,  X3.1 66-1 989) 

The  following  implementation  agreements  are  with  respect  to  the  FDDI  PMD  specification: 

1  Stations  shall  repeat  all  valid  packets  under  all  signal  conditions  specified  in  section  5.2  of  X3.166- 
1989,  "Active  Input  Interface",  with  a  bit  error  rate  (BER)  of  not  more  than  2.5  x  10'^°; 

2  Stations  shall  repeat  all  valid  packets  under  all  signal  conditions  specified  in  section  5.2,  "Active 
Input  interface",  except  that  the  Minimum  Average  Power  shall  be  -29  dBm  (2  dB  above  the 
specified  minimum),  with  a  BER  of  not  more  than  10"'^. 


6     Wid©  Area  Networks 


6.1      CCITT  Recomnnendation  X.25 

The  procedures  required  to  describe  the  DTE  side  of  a  DTE/DCE  interface  for  systems  attached  to  sub- 
networks providing  an  X.25  interface  shall  be  as  defined  in  ISO  7776  and  ISO  8208  and  as  supplemented 
below.  (These  procedures  shall  also  apply  to  a  DTE  operating  on  a  DTE/DTE  interface.) 


6.2       ISO  7776 

ISO  7776  is  used  as  the  Layer  2  Protocol  with  the  agreements  defined  below: 
a)  Address  assignment  information  is  as  follows: 

1)  DTE  =  A  (=11000000  binary); 

2)  DCE  =  B  (=10000000  binary); 

3)  On  a  DTE/DTE  interface,  one  of  the  DTEs,  by  a  prior  agreement,  shall  use  the  DCE 
address; 

-     '     b)  The  modulus  shall  be  8; 

c)  A  window  size  (k)  of  7  shall  be  supported.  In  addition,  other  window  sizes  may  also  be 
supported; 

d)  The  Multilink  Procedures  are  excluded. 
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The  elements  of  ISO  8208  applicable  for  use  depend  on  the  OSI  role  of  ISO  8208  (i.e.,  provision  of  CONS, 
support  of  CLNP).  Independent  of  the  role,  ISO  8208  is  used  as  the  Layer  3  protocol,  with  the  following 
agreements: 

a)  Virtual  Call  Service; 

b)  Any  mutually  agreed  window  and  packet  size,  however,  all  DTEs  must  be  capable  of  supporting 
a  window  size  of  2,  a  packet  size  of  128  octets,  and  a  sequence  number  modulus  of  8; 

c)  A  DTE  must  be  capable  of  receiving  the  Flow  Control  Parameter  Negotiation  Facility  and 
responding  appropriately  (per  ISO  8208); 

d)  The  Basic  RPOA  Selection  Facility  shall  be  implemented  and  its  use  or  non-use  selectable  on 
a  per  virtual  call  basis. 

When  ISO  8208  is  used  to  support  CONS,  the  optional  user  facilities  in  Clause  5.1  of  ISO  8878  shall  also 
be  supported. 

When  ISO  8208  is  used  to  support  CLNP  (when  providing  the  CLNS),  Permanent  Virtual  Circuit  Service  may 
also  be  used. 


7     Integrated  Services  Digital  Networks  (ISDN) 


7.1  Introduction 

This  clause  defines  Implementation  Agreements  for  packet-data  transfer  in  an  ISDN  context.  The  agreements 
provide  a  set  of  procedures  for  accessing  an  ISDN  so  that  end  systems  implemented  according  to  these 
agreements  can  obtain  ISDN  sen/ices  and  can  successfully  interoperate. 

The  agreements  are  not  meant  to  preclude  vendors  from  implementing  additional  procedures  as  long  as 
they  do  not  create  system  interoperability  problems.  Capabilities  will  vary  from  ISDN  to  ISDN  and 
procedures  beyond  those  included  here  may  be  necessary  to  request  and  utilize  network  services  more 
effectively  and  fully. 

The  agreements  cover  two  fundamental  ISDN  services  for  X.25  packet  mode  ISDN  terminals,  namely, 

CASE  I:  The  ISDN  provides  a  circuit-mode  (Layer  1)  connection  either  on  demand  ("switched")  or 

permanently  ("dedicated  circuit").  A  general  description  of  the  corresponding  ISDN  64  Kbps 
circuit-mode  bearer  service  is  described  in  CCITT  Recommendation  1.231 .  The  circuit-mode 
connection  is  between  an  X.25  ISDN  terminal  and  (i)  a  PSPDN,  or  (ii)  another  X.25  ISDN 
terminal.  The  circuit-mode  connection  to  a  PSPDN  corresponds  to  CASE  A  of  CCITT 
Recommendation  X.31. 

CASE  II:  The  ISDN  provides  the  X.25  virtual  circuit  service.  A  general  description  of  this  service  is 
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given  in  CCITT  Recomnnendation  1.232.  This  case  corresponds  to  CASE  B  of  CCITT 
Recommendation  X.31. 

Figures  4  and  5  give  tlie  agreed  stacks  for  X.25  packet  transfer  over  D  and  B  cfiannels,  respectively.  Some 
particular  aspects  are  given  below: 

a)  The  packet  data  transfer  is  on  a  B  channel  of  a  Basic  Access  or  a  Primary  Rate  Interface.  In 
CASE  II,  it  can  be  on  a  D  channel  of  a  Basic  Access  Interface; 

b)  The  layer  2  procedures  are  LAPS  (ISO  7776)  on  a  B  channel  and  LAPD  (CCITT 
Recommendation  Q.921)  on  a  D  channel; 

c)  X.25  PLP  (ISO  8208)  procedures  are  used,  including  the  setting  up  and  clearing  of  virtual  calls; 

;  d)  0.921  and  0.931  procedures  on  a  D  channel  are  used  for  access  signaling,  when  appropriate, 
to  select  the  B  or  D  channel  for  packet  data  transfer  and  for  establishing  and  releasing  a  physical 
path  in  the  ISDN; 

e)  Refer  to  part  3  for  the  specification  of  methods  for  providing  OSI  Network  Services. 


7.2      Implementation  Agreements 

This  clause  gives  Implementation  Agreements  for  individual  ISDN-related  protocols.  The  relevant  protocol 
stacks  are  given  in  figures  4  and  5. 

OSI  LAYER 


3 

Q.931 

ISO  8208 

(1.451) 

(X.25  PLP) 

2 

Q.921 

(1.441) 

(LAPD) 

1  1  ^'l 

D  CHANNEL 

1 

ANS  Tl. 601-1988, 

ANS  Tl. 605-1988 

ADDITIONAL  SIGNALING  PACKET  SWITCHED 

FOR  INCOMING  PACKET*       SIGNALING  AND  INFORMATION 
CALLS  TRANSFER 

*  MAY  BE  NULL 

Figure  4  -  Protocol  Layers  at  8,  T  and  U  reference  points  when  D  Channel  is  used  in  ISDN 
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OS  I  LAYER 


Q.931 
(1.451) 

ISO  8208 
(X.25  PLP) 

Q.921 

(LAPD) 

ISO  7776 
(X.25  LAPB) 

D  CHANNEL 


B  CHANNEL 


ANS  Tl. 601-1988,  ANS  Tl. 605-1988 
and  for  Primary  Rate  ANS  Tl. 408-1990 


 I  

Note  1  Note  2 

Figure  5  -  Protocol  Layers  at  S,  T  and  U  reference  points  when  B  Channel  is  used  in  ISDN 
NOTES 

1  This  refers  to  signaling  for  circuit  switched  access  (may  be  null),  as  well  as  additional  signaling  for  incoming 
packet  calls  (may  be  null). 

2  This  refers  to  packet  switched  signaling  and  information  transfer. 

7.2.1  Physical  Layer,  Basic  Access  at  "U" 

ANS  T1 .601-1988,  "Integrated  Sen/ices  Digital  Network-Basic  Access  Interface  for  Use  on  Metallic  Loops  for 
Application  on  the  Network  Side  of  the  NT  (Layer  1  Specification)"  applies. 

7.2.2  Ptiysical  Layer,  Basic  Access  at  S  and  T 

ANS  Tl  .605-1988,  "Integrated  Services  Digital  Network-Basic  Access  Interface  for  S  and  T  Reference  Points- 
Layer  1  Specification"  applies. 


7.2.3       Physical  Layer,  Primary  Rate  at  S,  T,  and  U 

ANS  Tl  .408-1 990,  "ISDN  Primary  Rate  -  Customer  Installation  Metallic  Interfaces  -  Layer  1  Specification" 
applies. 
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7.2.4       Data  Link  Layer,  D-Channel 

CCITT  Recommendation  Q.921  (1.441),  "ISDN  User-Network  Interface,  Data  Link  Layer  Specification"  applies. 


7.2.5  Signaling 

CCITT  Recommendation  Q.931  (1.451),  "ISDN  User-Network  Interface  Layer  3  Specification  for  Basic  Call 
Control"  applies. 

The  following  agreements  hiave  been  reached  concerning  the  use  of  Q.931 : 

a)  On  a  Basic  Rate  Interface  supporting  the  ISDN  virtual  circuit  sen/ice,  all  of  Q.931  section  6 
except  for  6.1.1  and  6.2.1  (the  sections  covering  the  circuit-switched  access  case)  shall  apply.  The 
following  sections  also  apply:  2.2,  packet  mode  access  connection  states;  3.2,  messages  for  packet 
mode  access  connection  control;  4-4.5,  section  specifying  general  information  element  handling  and 
encoding;  4.7,  information  elements  for  packet  communications; 

b)  On  a  Primary  Rate  Interface  supporting  the  ISDN  virtual  circuit  service  all  of  Q.931  section  6  shall 
apply  except  for  6.1.1  and  6.2.1  (the  sections  specifying  the  circuit  switched  access  case),  6.1.2.2, 
6.2.2.2  and  6.4.2  (the  sections  specifying  D-Channel  ISDN  Virtual  Circuit  service  case).  The  following 
sections  also  apply:  2.2,  packet  mode  access  connection  states;  3.2,  messages  for  packet  mode 

u  irnc  access  connection  control;  4-4.5,  sections  specifying  general  information  element  handling  and 
encoding;  4.7,  information  elements  for  packet  communications; 

c)  On  a  Basic  or  Primary  Rate  Interface  supporting  the  unrestricted  64-Kbps  circuit-mode  service, 
Q.931  sections  6.1 .1 ,  6.2.1 , 6.4.1  and  6.4.3  shall  apply.  The  following  sections  also  apply:  2.1 ,  circuit 
mode  connection  states;  3.1,  messages  for  circuit  mode  connection  control;  4-4.5,  sections 
specifying  general  information  element  handling  and  encoding. 


7.2.6       Data  Link  Layer  B-Channel 

The  agreements  on  ISO  7776  specified  in  6.2  shall  apply  here. 

If  the  ISDN  provides  a  circuit-mode  service  between  two  ISDN  packet-mode  devices,  then  the  layer  2 
address  shall  be  assigned  as  follows: 

a)  For  permanent  ("non-switched")  circuit-mode  service,  one  terminal  uses  address  A  and  the  other 
terminal  uses  address  B,  as  arranged  by  prior  agreement; 

b)  For  demand  ("switched")  circuit-mode  service,  the  terminal  originating  the  circuit-mode  call  uses 
'  k      address  A  and  the  other  terminal  uses  address  B. 
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7.2.7       Packet  Layer 

The  agreements  on  ISO  8208  specified  in  6.3  sfiall  apply  here.  When  ISO  8208  Is  used  on  the  D-Channel, 
the  maximum  DATA  packet  size  (i.e.,  actually  the  maximum  size  of  the  User  Data  Field  in  a  DATA  packet) 
shall  be  limited  to  256  octets. 
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Annex  A  (informative) 

Cross  Reference  Between  CCITT  and  ANSI  Text  Relating  to  ISDN 
Agreements 

This  annex  provides  a  cross-reference  listing  between  tliose  sections  of  tfie  CCITT  ISDN  Recommendations 
given  in  clause  7  of  this  document  and  the  sections  of  the  corresponding  ANSI  ISDN  Standards.  This 
appendix  does  not  supersede  clause  7  but  merely  provides  a  pointer  to  those  who  wish  to  implement  the 
ISDN  procedures  based  on  ANSI  Standards. 

A.I      Data  Link  Layer,  D-Channel 


CCITT  Recommendation  Q.921,  which  is  referenced  in  7.2.4  of  this  document,  is  identical  to  ANSI  Standard 
T1.602. 


A.2  Signaling 

The  following  table  provides  the  cross-references  between  those  sections  of  CCITT  Recommendation  Q.931 
referenced  in  7.2.5  of  this  document  and  the  corresponding  ANSI  ISDN  Standards. 


Table  1  -  ANSI-CCITT  cross-references 


CCITT  RECOMMENDATION  Q.931 

ANSI  Tl. 

608 

Section 

2.1 

Section 

4.1  (refers  to  sec. 

2.1.1 

of  ANSI  T1.607) 

Section 

2.2 

Section 

4.2 

Section 

3.1 

Section 

5.1  (refers  to  sec. 

3  of  ANSI  T1.607) 

Section 

3.2 

Section 

5.2 

Section 

4.1 

Section 

6.1 

Section 

4.2 

Section 

6,2 

Section 

4.3 

Section 

6.3 

Section 

4.4 

Section 

6.4 

Section 

4.5 

Section 

6.5 

Section 

4.7 

Section 

6.5 

Section 

6 

Section 

7 

Section 

6.1.1 

Section 

7.1.1 

Section 

6.1.2.2 

Section 

7.1.2.2 

Section 

6.2.1 

Section 

7.2.1 

Section 

6.2.2.2 

Section 

7.2.2.3 

Section 

6.4.1 

Section 

7.4.1 

Section 

6.4.2 

Section 

7.4.2 

Section 

6.4.3 

Section 

7.4.3 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest  Group 
(LLSIG)  of  the  Open  Systems  Interconnection  Implementors'  Workshop  (OIW).  See  Procedures  Manual  for 
Workshop  charter.  ^ 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject.  Significant  technical  changes  from  this  text  as  previously 
given  are  addressing-related  and  routeing-related.  References  are  made  to  Part  2  in  this  part. 

Annex  A  is  for  information  only. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  3  -  Network  Layer 


1  Introduction 

This  part  presents  agreements  for  providing  the  OS!  network  service.  Also  contained  here  are  agreements 
on  network  layer  addressing  and  routing. 


1  Scope 

These  agreements  cover  both  connectionless-mode  and  connection-mode  network  services. 


2     Normative  References 


2.1  CCITT 

[1]       Recommendation  X.213  (Blue  Book,  1988),  Network  Service  Definition  for  Open  Systems 
Interconnection  for  CCITT  Applications. 


2.2  ISO 

[2]       ISO  8348,  Information  processing  systems  -  Data  communications  -  Network  service  definition. 

[3]  ISO  8348  Addendum  1 ,  Information  processing  systems  -  Data  communications  -  Network  sen/ice 
definition  •  Addendum  1:  Connectionless-mode  transmission. 

[4]  ISO  8348  Addendum  2,  Information  processing  systems  -  Data  communications  -  Network  sen/ice 
definition  -  Addendum  2:  Network  layer  addressing. 

[5]  ISO  8473,  Information  processing  systems  -  Data  communications  -  Protocol  for  providing  the 
connectionless-mode  network  service. 

[6]  ISO  8648,  Information  processing  systems  -  Open  systems  interconnection  -  Internal  organization 
of  the  Network  Layer. 

[7]  ISO  8878,  Information  processing  systems  -  Data  communications  -  Use  ofX.25  to  provide  the  OSI 
connection-mode  network  service. 

[8]  ISO  8881 ,  Information  processing  systems  -  Data  communications  -  Use  of  the  X.25  packet  level 
protocol  in  local  area  networks. 

[9]  ISO  9542,  Information  processing  systems  -  Telecommunications  and  information  exchange 
between  systems  -  End  system  to  Intermediate  system  routing  exchange  protocol  for  use  in 
conjunction  with  the  Protocol  for  providing  the  connectionless-mode  sen/ice  (ISO  8473). 
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[10]  ISO/IEC  9574,  Information  technology  -  Telecommunications  and  information  exchange  between 
systems  -  Provision  of  the  OSI  connection-mode  network  service  by  packet  mode  terminal 
equipment  connected  to  an  integrated  services  digital  network  (ISDN). 

[11]  ISO/IEC  TR  9577,  Information  technology-  Telecommunications  and  information  exchange  between 
systems  -  Protocol  identification  in  the  network  layer. 

[12]  ISO/IEC  TR  10029,  Information  technology  -  Telecommunications  and  information  exchange 
between  systems  -  Operation  of  an  X.25  interworking  unit. 

[13]  ISO/IEC  10030,  Information  processing  systems  -  Telecommunications  and  information  exchange 
between  systems  -  End  system  routeing  information  exchange  protocol  for  use  in  conjunction  with 
ISO  8878. 


3  Status 

This  version  of  the  agreements  was  completed  in  December  1990. 


4  Errata 

This  clause  may  contain  "Defect  Report"  and  resolutions  material,  and  the  versions  of  implementor 
agreements  to  which  this  material  applies. 

The  following  defects  are  being  progressed  in  ISO: 

a)  ISO  9542,  defect  1,  Parts  1-13. 


5     Connectionless-Mode  Network  Service  (CLNS) 


5.1      ISO  8473 

Subsets  of  the  protocol  are  as  follows: 

a)  Implementations  will  not  transmit  PDUs  encoded  using  the  inactive  subset.  Received  PDUs 
■  '     encoded  using  the  inactive  subset  will  be  discarded; 

b)  The  non-segmenting  subset  will  not  be  used.  Implementations  will  not  generate  data  PDUs 
without  a  segmentation  part.  However,  implementations  will  receive  and  correctly  process  PDUs 
which  do  not  contain  the  segmentation  part. 

Mandatory  Functions  of  ISO  8473  are  as  follows: 

:       a)  The  lifetime  parameter  shall  be  used  as  specified  in  clause  6.4  of  ISO  8473.  The  parameter  shall 
have  an  initial  value  of  at  least  three  times  the  network  span  or  three  times  the  maximum  transit 
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delay  (In  units  of  500  ms),  whichever  Is  greater; 

b)  The  reassembly  timer  for  an  Initial  PDU  at  the  reassembly  point  shall  be  no  greater  than  the 
largest  value  of  all  lifetime  parameters  contained  in  all  derived  PDUs; 

c)  The  use/non-use  of  checksums  shall  be  capable  of  being  configured.  The  default  setting  shall 
be  non-use; 

d)  If  the  implementation  supports  the  generation  of  an  ER  PDU,  the  system  shall  insert  in  the 
destination  address  field  of  the  ER  PDU  the  contents  of  the  source  address  field  of  the  PDU  that 
generated  the  error; 

e)  For  the  purposes  of  relaying  and  routing,  a  protocol  entity  need  not  verify  the  correctness  of  ISO 
8348/Add.  2  semantics  carried  in  NPAI  of  received  PDUs. 

Optional  Functions  of  ISO  8473  are  as  follows: 

a)  The  Security  parameter  is  not  defined  by  these  Agreements.  Implementations  shall  not  transmit 
the  parameter  except  where  defined  by  bilateral  agreements; 

b)  Partial  and  complete  source  routing  will  not  be  supported;^ 

c)  Partial  record  of  route  will  be  supported  by  Intermediate  systems; 

d)  ISO  8473  will  be  followed  with  respect  to  QOS; 

e)  For  systems  implementing  the  congestion  notification  function,  the  following  applies: 

1)  A  Globally  Unique  QOS  Maintenance  parameter  shall  be  included  in  all  PDU  originated 
by  End  Systems.  As  specified  in  ISO  8473,  the  initial  value  of  the  Congestion  Experienced 
flag  (CE  flag)  within  the  Globally  Unique  QOS  Maintenance  Parameter  shall  be  set  by  the 
originating  End  System  to  zero.  All  other  flags  within  the  Globally  Unique  QOS  Maintenance 
Parameter  shall  be  set  based  on  the  specific  local  needs  of  the  originating  End  System; 

2)  Intermediate  systems  not  implementing  queue  length  averaging  shall  leave  the  CE  flag 
in  the  same  state  as  it  was  received.  In  particular,  no  intermediate  system  (IS)  shall  ever 
clear  (set  to  zero)  the  CE  flag.  All  intermediate  systems  shall  monitor  all  incoming  and 
outgoing  queues  and  compute  average  queue  lengths  as  shown  by  example  in  figure  1 . 
The  averaging  Is  done  from  the  beginning  of  the  previous  cycle  to  the  current  time.  A  cycle 
begins  at  the  instant  of  the  first  NSDU  arrival  after  an  idle  period; 

3)  An  IS  should  set  the  CE  flag  in  all  NSDUs  fonwarded  on  a  queue  which  has  an  average 
queue  length  greater  than  one; 

4)  The  queue  length  averaging  algorithm  computes  the  average  queue  length  over  two 


A  defect  exists  with  the  Partial  Source  Routing  option  which  can  cause  PDUs  to  loop  in  the 
network  until  their  lifetime  expires. 
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cycles,  where  the  two  cycles  are: 

a)  the  "previous  cycle",  which  is  the  interval  from  when  the  IS  becomes  busy,  until 
it  becomes  idle  and  the  idle  ends  (indicated  by  the  instant  the  first  packet  arrives 
to  the  idle  IS); 

b)  the  "current  cycle",  which  is  the  interval  from  the  end  of  the  idle  interval  to  the 
current  time  instant  when  the  average  queue  length  is  computed; 

5)  An  embodiment  of  the  averaging  algorithm  is  shown  in  figure  1 ; 

f)  Refer  to  the  Working  Implementation  Agreements  document  for  additional  optional  functions. 


The  algorithm  makes  use  of  the  following  variables: 
t  =  Current  time 

tj^  =  time  of  i^"  arrival  or  departure  event 
qj^  =  number  of  packets  in  the  system  after  the  event 
Tq  =  time  at  the  beginning  of  the  previous  cycle 
T-^  =  time  at  the  beginning  of  the  current  cycle 

The  algorithm  consists  of  three  components: 

1.  Queue  Length  Update:  Beginning  with  qQ  =  0, 

If  the  i^JJ  event  is  an  arrival  event,        =  q^_-^+l 
If  the  i^"  event  is  a  departure  event,  qj^  =  qj^_3^-l 

2.  Queue  Area  (integral)  update: 

Area  of  the  previous  cycle  =  2    ^i-i ( ti-t^_2^ ) 

tie{To,Ti) 

Area  of  the  current  cycle  =  Z  ( ti-ti_3^ ) 

ti£{Ti,tT 

3.  Average  Queue  Length  Update: 

Average  Queue  length  over  the  two  cycles 

Area  of  the  two  cycles      Area  of  the  two  cycles 

Time  of  the  two  cycles  t-Tg 


Figure  1  -  Queue  length  averaging  algorithm 
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5.2  Provision  of  CLNS  over  Local  Area  Networks  (LANS) 

When  providing  CLNS  over  a  LAN  subnetwork,  the  following  shall  apply: 

a)  The  definition  of  CLNS  shall  be  as  specified  in  ISO  8348/Add.  1 ; 

b)  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473  with  agreements  as  specified  in  5.1; 

c)  The  necessary  subnetwork  dependent  convergence  function  shall  be  as  defined  in  ISO  8473  - 
clause  8.4.2.  "SNDCF  used  with  ISO  8802/2  sub-networks." 

5.3  Provision  of  CLNS  over  X.25  Subnetworks 

When  providing  CLNS  over  X.25  subnetworks,  the  following  shall  apply: 

a)  The  definition  of  CLNS  shall  be  as  specified  in  ISO  8348/Add.  1; 

b)  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473  with  agreements  as  specified  in  5.1; 

c)  The  necessary  subnetwork  dependent  convergence  function  shall  be  as  defined  in  ISO  8473  - 
clause  8.4.3,  "SNDCF  used  with  ISO  8208  subnetworks  for  operation  over  X.25  subnetworks,"  and 
the  default  throughput  class  shall  be  used  if  this  facility  is  available; 

d)  The  X.25  PLP  shall  be  as  specified  in  part  2  clause  6.3. 

5.4  Provision  of  CLNS  over  ISDN 

When  providing  CLNS  over  an  ISDN,  the  following  shall  apply: 

a)  The  definition  of  CLNS  shall  be  as  specified  in  ISO  8348/Add.  1; 

b)  The  protocol  used  to  provide  CLNS  shall  be  ISO  8473  with  agreements  as  specified  in  5.1; 

c)  The  necessary  Subnetwork  Dependent  Convergence  function  shall  be  as  defined  in: 

1)  ISO  8473  for  operation  of  CLNP  over  X.25  with  agreements  as  specified  in  5.3; 

2)  ISO  9574  for  control  of  the  B  and  D  channels; 

3)  The  X.25  PLP  shall  be  as  specified  in  part  2,  clause  6.3; 

4)  The  agreements  for  the  ISDN-related  protocols  are  specified  in  part  2,  clause  7. 

NOTE  -  The  stated  scope  of  ISO  9574  does  not  explicitly  cover  the  operation  of  CLNP  over  an  ISDN. 
However,  the  procedure  identified  for  operating  X.25  in  conjunction  with  1.451  is  still  applicable.  The  procedures 
in  ISO  9574  that  correspond  to  8878  are  not  utilized  when  providing  CLNS. 
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5.5      Provision  of  CLNS  over  Point-to-Point  Links 

Refer  to  the  Working  Implementation  Agreements  document. 

6     Connection-Mode  Network  Service  (CONS) 

The  following  agreements  concern  provision  of  the  connection-mode  Network  Sen/ice. 

6.1      Mandatory  Method  of  Providing  CONS 

6.1.1  General 

Independent  of  the  subnetwork  type  (of  part  2),  when  providing  the  CONS  using  X.25-1984,  the  following 
shall  apply  as  described  below: 

a)  The  definition  of  the  CONS  is  as  specified  in  ISO  8348,  Network  Sen/ice  Definition: 

b)  The  mapping  of  the  elements  of  the  CONS  to  the  elements  of  the  X.25  Packet  Layer  Protocol 
(PLP)  is  as  specified  in  6.3.1; 

c)  The  general  procedures  and  formats  of  the  X.25  PLP  are  as  specified  in  ISO  8208,  X.25 
Packet  Layer  Protocol  for  Data  Terminal  Equipment. 

6.1.2  X.25  WAN 

No  provisions  additional  to  those  in  6.1.1  apply  in  an  X.25  WAN. 

6.1.3  lAHs 

When  providing  the  CONS  in  a  Local  Area  Network,  the  following  aspects  of  ISO  8881 ,  In  addition  to  the 
documents  listed  in  6.1.1,  shall  apply: 

a)  Clauses  1-6  and  9-11  for  LLC  Type  1  operation,  including  the  additional  nonstandard  default 
packet  size  listed  in  Clause  6.3,  Note  2. 

NOTE  -  Operation  of  ISO  8208  in  conjunction  with  LLC  Type  2  requires  agreement  on  LLC  Type  2 
procedures. 
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6.1.4  ISDN 

When  providing  the  CONS  in  an  ISDN,  the  considerations  for  control  of  a  B  and  D  channel  in  ISO  9574, 
in  addition  to  those  provided  in  6.1.1,  shall  apply. 

6.2  Additional  Option:  Provision  of  CONS  over  X.25  1980 
Subnetworks 

When  providing  CONS  over  an  X.25  1980  subnetwork,  the  following  shall  apply: 

a)  The  definition  of  the  CONS  is  as  specified  in  ISO  8348,  Network  Service  Definition: 

b)  The  subnetwork  dependent  convergence  protocol  required  to  provide  CONS  shall  be  as 
specified  in  ISO  8878  Annex  A,  and  referred  to  as  the  Alternative  Procedures  for  Network 
Connection  Establishment  and  Release,  with  agreements  as  defined  in  6.3.2. 

6.3  Agreements  on  Protocols 


6.3.1  ISO  8878 

ISO  8878  Clauses  1-11  shall  apply  with  the  following  exception: 

a)  Where  the  ISO  8208  diagnostic  codes  are  not  provided,  all  Cause/Diagnostic  code 
combinations  can  be  mapped  to  the  Originator/Reason  code  of  "Undefined." 

6.3.2  Subnetwork  Dependent  Convergence  Protocol  (ISO  8878/Annex  A) 

The  Receipt  Confirmation  service  will  not  be  provided,  so  the  corresponding  protocol  elements  need  not 
be  implemented. 

The  Expedited  Data  sen/ice  will  not  be  provided,  so  the  corresponding  protocol  elements  need  not  be 
implemented. 


6.4  Interworking 

Interworking  between  subnetworks  whose  End  Systems  use  ISO  8208  to  provide  the  CONS  as  specified 
in  6.1  shall  be  performed  as  specified  in  ISO  TR  10029.  That  is,  an  Intermediate  System  connecting  two 
such  subnetworks  shall  operate  ISO  8208  on  both  subnetworks  and  shall  relay  information  from  one 
subnetwork  to  the  other  as  described  in  ISO  TR  10029. 
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7  Addressing 

NSAP  address  formats  supported  will  conform  to  Addendum  2  of  ISO  8348  as  follows: 

a)  NSAP  address  formats  will  have  a  hierarchical  structure.  This  will  reduce  the  size  of  routing 
tables; 

b)  If  used  in  the  Domain  Specific  Part  (DSP),  an  NSAP  selector  shall  be  the  least  significant 
component  in  the  hierarchy,  and  shall  be  encoded  as  the  last  octet  of  the  DSP.  The  NSAP 
selector  shall  not  be  used  to  perform  routing;  it  is  simply  intended  to  identify  the  network  service 
user  at  the  destination  end  system.  For  those  implementations  using  an  NSAP  selector,  there 

'         shall  be  one  and  only  one  selector  for  each  NSAP  within  the  end  system.  All  NSAP  addresses 
identifying  a  given  NSAP  will  use  the  same  NSAP  selector  value. 

c)  In  routing  environments  in  which  systems  support  NSAP  addresses  containing  selectors  as 
specified  in  b),  the  corresponding  Network  Entity  Titles  shall  have  the  same  format  with  the 
NSAP  selector  set  to  zero. 

d)  End  Systems  and  Intermediate  Systems  operating  in  routing  domains  that  employ  the  ISO 
10589  Intradomain  Routing  Protocol  shall  meet  the  NSAP/NET  addressing  requirements 
specified  in  ISO  10589  (clause  7.1)  and  clause  8.3  of  these  agreements. 


NOTE  -  This  may  be  incompatible  with  systems  implemented  according  to  previous  versions  of  these 
agreements. 


8  Routing 

The  basic  principles  of  Network  Layer  routing  are  defined  in  the  OSI  Routing  Framework  ISO/IEC  TR 
9575.  These  principles  state  that: 

a)  The  global  OSI  environment  will  consist  of  a  number  of  Administrative  Domains,  An 
Administrative  Domain  consists  of  a  collection  of  End  Systems  (ESs)  and  Intermediate  Systems 
(ISs),  and  subnetworks  operated  by  a  single  organization  or  Administrative  Authority.  The 
Administrative  Authority  is  responsible  for:  the  organization  of  ESs  and  ISs  into  Routing 
Domains;  the  assignments  of  NSAP  and  SNPA  addresses;  the  policies  that  govern  resource 
usage;  the  policies  that  govern  the  information  that  is  collected  and  disseminated  both  internally 
and  externally  to  the  Administrative  Domain;  and  the  establishment  of  subdomains  and  the 
corresponding  delegation  of  responsibilities; 

b)  A  Routing  Domain  is  a  set  of  ESs  and  ISs  which  operate  according  to  the  same  routing 
procedures  and  which  is  wholly  contained  within  a  single  Administrative  Domain.  An 
Administrative  Authority  may  delegate  to  the  entity  responsible  for  a  Routing  Domain  the 
responsibilities  to  further  structure  and  assign  NSAP  and  SNPA  addresses.  The  hierarchical 
decomposition  of  Routing  Domains  into  subdomains  may  greatly  reduce  the  resources  required 
in  the  maintenance,  computation,  and  storage  of  routing  information; 

c)  The  OSI  routing  problem,  and  consequently  OSI  routing  protocols,  has  been  decomposed 
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into  three  distinct  classes: 

1)  End  System  (ES)  to  Intermediate  System  (IS)  routing  witfiin  a  single  subnetwork; 

2)  IS  to  IS  routing  witiiin  a  single  routing  domain  (Intra-domain); 

3)  IS  to  IS  routing  between  routing  domains  (Inter-domain). 


8.1      ISO  9542  End  System  to  Intermediate  System  Routing 

For  use  in  conjunction  with  ISO  8473,  ISO  9542  shall  be  used  to  provide  the  routing  exchange  protocol. 

Additionally,  a  management  mechanism  capable  of  adding  and  deleting  entries  into  the  Routing 
Information  Base  (RIB)  is  recommended.  When  using  the  management  mechanism  to  add  an  entry, 
there  should  be  no  holding  timer,  and  the  entry  should  be  write  protected  from  alteration  by  the  ES-IS 
protocol.  This  mechanism  enables  routing  table  entries  to  be  made  which  are  static  in  nature. 

The  agreements  below  apply  to  the  use  of  ISO  9542: 

a)  Implementors  shall  support  any  valid  NSAP  format.  For  the  purposes  of  the  protocol,  NSAP 
addresses  are  treated  simply  as  octet  strings; 

b)  For  LANs,  implementors  shall  support  both  Configuration  Information  and  Route  Redirection 
Information;  no  subsets  are  permitted.  For  X.25  subnetworks,  Route  Redirection  information 
shall  be  supported; 

c)  Ail  timer  values  shall  be  configurable; 

d)  Use  or  non-use  of  checksums  shall  be  configurable.  It  is  recommended  not  to  use  ISO  9542 
checksums  when  originating  PDUs; 

e)  The  QOS,  Security  and  Priority  parameters  should  not  be  used  for  routing.  For  conformance, 
intermediate  systems  must  transmit  these  parameters  in  RD  PDUs  if  they  are  present  in  the  data 
PDU  which  generated  the  redirect.  However,  end  systems  must  ignore  them  in  received  RD 
PDUs; 

f)  If  the  configuration  notification  function  described  in  6.7  of  the  protocol  specification  is 
implemented,  a  mechanism  shall  be  provided  to  enable/disable  this  function  on  broadcast 
networks.  If  supported  in  end  systems  listening  to  both  ISHs  and  ESHs,  this  function  shall  only 
be  invoked  upon  receipt  of  an  ISH.  Alternate  mechanisms  for  ISs  and  ESs  are  described  in  8.1.1 
and  8.1.2. 

g)  For  LANs,  this  protocol  employs  the  same  LSAP  as  ISO  8473; 

h)  The  encoding  of  the  BSNPA  address  follows  the  syntax  rules  for  the  data  link  being  used.  On 
a  l_AN,  for  example,  it  is  a  48-bit  MAC  address  encoded  as  specified  in  clause  12.2.1.4  of  ISO 
10039.  On  X.25  subnetworks,  it  is  a  DTE  address,  each  digit  being  binary  coded  in  a  semi-octet, 
and,  if  there  are  an  odd  number  of  digits,  an  additional  semi-octet  set  to  the  value  1111  shall  be 
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added  at  the  end; 

i)  The  multicast  addresses  corresponding  to  "Ail  Intermediate  Systems  on  the  Network" 
(ALLJSN)  and  "All  End  Systems  on  the  Network"  (ALL_ESN)  shall  default  to  the  following  on 
IEEE802.3  and  IEEE802.4  subnetworks: 

1)  ALL_ESN  =  09-00-2B-00-00-04,  ALL_ISN  =  09-00-2B-00-00-05; 

2)  It  is  understood  that  the  hexadecimal  octets  shown  are  transmitted  onto  the  medium 
from  left  most  octet  to  right  most  octet.  Within  each  hexadecimal  octet  the  least 
significant  bit  is  transmitted  first; 

j)  The  multicast  addresses  corresponding  to  "All  Intermediate  Systems  on  the  Network" 
(ALL_ISN)  and  "All  End  Systems  on  the  Network"  (ALL_ESN)  shall  default  to  the  following  two 
functional  addresses  on  IEEE802.5  subnetworks: 

1)  ALL_ESN  =  COOO  0000  4000,  ALLJSN  =  COOO  0000  8000; 

2)  It  is  understood  that  the  hexadecimal  octets  shown  are  transmitted  onto  the  medium 
from  left  most  octet  to  right  most  octet.  Within  each  hexadecimal  octet  the  most 
significant  bit  is  transmitted  first; 


Editor's  Note  -  Note  that  in  the  hexadecimal  representation  defined  in  ISO  10039,  these  addresses  would 
be: 

1)  ALL_ESN  -  03-00-00-00-02-00 

2)  ALLJSN  =  03-00-00-00-01-00 


NOTE  -  This  notation  presents  the  octet  values  such  that  the  least  significant  bit  is  that  transmitted  first. 

k)  The  Error  Report  flag  shall  be  set  to  zero  (0)  for  NPDUs  sent  as  a  result  of  invoking  the 
QUERY  Configuration  Function. 

I)  ISO  8473  PDUs  multicast  as  a  result  of  the  Query  Configuration  function  shall  use  the 
Network  Layer  Protocol  ID  (NLPID)  assigned  to  ISO  8473. 

m)  An  ISO  8473  PDU  received  as  a  result  of  another  ES  having  performed  the  Query 
Configuration  function  shall  be  processed  as  follows: 

1)  If  the  ISO  8473  PDU  is  addressed  to  one  of  the  NSAPs  present  in  the  ES,  the  End 
System  shall  process  the  PDU  according  to  the  applicable  clauses  of  ISO  8473  and 
invoke  the  Configuration  Response  Function  (clause  6.6  of  ISO  9542); 

2)  If  the  ISO  8473  PDU  is  not  addressed  to  one  of  the  NSAPs  present  in  the  ES,  the 
End  System  shall  discard  the  PDU  without  generating  an  ISO  8473  Error  Report; 

n)  For  purposes  of  address  matching  and  SNPA  extraction,  the  first  octet  of  the  option 
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parameter  value  of  an  address  (clause  7.4.5)  or  SNPA  Mask  (clause  7.4.6)  shall  be  aligned  with 
the  first  octet  (AFI)  of  the  encoded  trial  NSAP  Address. 


The  following  items  represent  proposed  solutions  to  defects  in  ISO  9542.  These  solutions  are  being 
progressed  as  defect  reports  to  ISO  9542.  These  items  will  be  deleted  when  the  corresponding  defect 
report  is  approved: 

a)  An  End  System  may  choose  to  ignore  an  RD  PDU  received  for  a  destination  to  which  the  ES 
has  not  sent  traffic  for  some  period  of  time.  An  ES  must  record  redirection  information  only  for 
those  other  systems  with  which  it  is  in  active  communication; 


b)  A  holding  time  value  of  zero  is  permitted.  When  configuration  and/or  redirection  information 
with  a  zero  holding  time  is  received,  prior  information  shall  be  replaced,  thus  causing  the  system 
to  set  its  holding  timer  to  zero  and  discard  the  corresponding  information; 


c)  If  one  or  more  iSs  suggested  an  ESCT,  the  minimum  of  the  non-zero  suggested  values 
replaces  the  current  value  of  the  ES's  CT. 


8.1.1       Alternative  Configuration  Mechanism  -  iS  Actions 

An  alternative  mechanism  for  achieving  rapid  configuration  which  is  scaieable  to  large  broadcast 
networks  is  described  below.  This  mechanism  makes  use  of  the  Suggested  ES  Configuration  Timer. 
Implementation  of  this  mechanism  is  optional. 

When  an  Intermediate  system  wants  to  quickly  acquire  the  End  system  configuration  (for  example,  when 
a  broadcast  circuit  is  enabled  on  the  IS  or  the  topology  changes  because  of  a  failure  of  a  bridge  or 
repeater),  it  initiates  a  "poll"  of  the  End  system  configuration  by  performing  the  following  actions: 

a)  Delay  a  random  interval  between  0  and  PollESHeiloRate  seconds.  (This  is  to  avoid 
synchronization  with  other  ISs  which  have  detected  a  change.); 

b)  In  order  to  rapidly  time  out  any  End  systems  which  are  no  longer  present  on  the  broadcast 
circuit  (for  example,  after  a  LAN  partition),  reset  the  entryRemainingTime  in  the  Routing 
Information  Base  for  all  End  systems  on  this  circuit  to  the  value:  (ISHelloTimer  + 
PollESHeiloRate)  *  HoldingMultiplier  or  the  existing  value  whichever  is  lowest.  Where 
ISHelloTimer  is  the  Intermediate  system's  configuration  timer,  HoldingMultiplier  is  a  predefined 
number  (for  example,  2)  which  multiplied  by  ISHelloTimer  gives  the  value  for  the  Holding  Time 
field  of  IS  Helios; 

c)  Then  transmit  HoldingMultiplier  IS  Helios  with  a  Suggested  ES  Configuration  Timer  value  of 
PollESHeiloRate  seconds  with  an  interval  of  ISHelloTimer  seconds  between  each  and  setting  the 
Holding  Time  field  to  ISHelloTimer  *  HoldingMultiplier; 

d)  Then  start  sending  IS  Helios  with  a  Suggested  ES  Configuration  Timer  of  DefaultESHelioRate 
seconds  (where  DefaultESHelioRate  is  larger  than  PollESHeiloRate). 
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8.1.2       Alternate  Configuration  Mechanism  -  ES  Actions 

An  End  system  maintains  for  each  circuit  a  list  (CTList)  which  has  HoldingiVlultiplier  elements  each  of 
which  stores  a  received  value  of  the  Suggested  ES  Configuration  Timer.  The  function  SaveCT(t)  adds  the 
value  t  as  the  first  element  of  CTList  and  discards  the  last  element.  The  function  MinCT  delivers  the 
minimum  value  in  CTList.  When  the  circuit  is  enabled  all  the  elements  of  CTList  are  initialized  to 
PollESHelloRate. 

An  End  system  also  maintains  for  each  circuit  the  variables  currentSuggestedHelloTimer  and  its 
associated  lifetime  currentSuggestedHelloTimerLifetime.  These  are  both  initialized  to  PollESHelloRate. 

When  the  circuit  Is  enabled  the  Configuration  Timer  is  started  by  setting  the  entryRemainingTime  to 
random  (PollESHelloRate). 

On  Configuration  Timer  expiry  the  following  actions  are  performed: 

a)  SaveCT(currentSuggestedHelloTimer); 

b)  Transmit  an  ES  Hello  with  Holding  Time  field  set  to  MinCT  *  HoldingMultiplier; 

c)  Set  entryRemainingTime  to  MinCT  -  random(MinCT  *  0.25).  (The  random  element  ensures 
that  End  systems  do  not  become  synchronized.) 

When  an  End  system  receives  an  IS  Hello  which  contains  a  Suggested  ES  Configuration  Timer,  it  is 
processed  as  follows  (where  suggestedESCT  is  the  value  contained  in  the  option): 

a)  If  suggestedESCT  is  less  than  or  equal  to  currentSuggestedHelloTimer  then  set 
curentSuggestedHelloTimerLifetime  to  the  value  of  the  Holding  Time  field  of  the  IS  Hello; 

b)  If  suggestedESCT  is  less  than  currentSuggestedHelloTimer  then  set 
currentSuggestedHelloTimer  to  suggestedESCT  and  reset  entryRemainingTime  to  the  smaller  of 
its  current  value  and  random(currentSuggestedHelIoTimer  *  0.75). 

When  the  currentSuggestedHelloTimerLifetime  expires,  set  the  currentSuggestedHelloTimer  to 
DefaultESHelloTimer. 


8.2      ISO  10030  End  System  to  Intermediate  System  Routing 

The  protocol  used  to  provide  End  System  to  Intermediate  System  routing  in  support  of  the  CONS  (refer 
to  3.6)  shall  be  ISO  10030. 

The  following  agreements  apply  to  the  use  of  ISO  10030: 

a)  A  management  mechanism  capable  of  adding  and  deleting  entries  in  the  Routing  Information 
Base  (RIB)  of  both  SNAREs  and  End  Systems  is  recommended.  When  using  the  management 
mechanism  to  add  an  entry  it  should  not  be  timed  out,  and  the  entry  should  be  write  protected 
from  alteration  by  the  ISO  10030  protocol. 
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b)  The  multicast  addresses  corresponding  to  "All  CONS  End  Systems"  and  "All  CONS  SNAREs" 
shall  default  to  the  following  on  IEEE  802.3  and  IEEE  802.4  subnetworks: 

1)  All  CONS  End  Systems  =  01-80-C2-00-00-16 

2)  All  CONS  SNAREs       =  01-80-02-00-00-17 

8.3  Intra-Domain  Intermediate  Systems  to  Intermediate  Systems 
Routing 

Intermediate  systems  shall  provide  mechanisms  to  create  and  update  the  required  Routing  Information 
Base. 

The  protocol  used  to  provide  Intermediate  System  to  Intermediate  System  routing  in  support  of  the 
CLNS  (refer  to  clause  3.5)  among  systems  in  a  single  routing  domain  shall  be  ISO  10589. 

The  following  agreements  apply  to  the  use  of  ISO  10589: 

a)  A  management  mechanism  capable  of  configuring  the  Identifier,  Characteristic,  and  Status 
attributes  of  the  managed  objects  of  clause  1 1  shall  be  provided; 

b)  The  implementation  shall  support  a  system  identifier  (ID)  length  of  6  octets  and  shall  use  this 
value  as  a  default. 

8.4  Inter-Domain  Intermediate  Systems  to  Intermediate  Systems 
Routing 

An  Administrative  Authority  shall  determine  the  procedures  and  policies  that  govern  the  exchange  of 
routing  information  with  other  routing  domains. 

Intermediate  systems  shall  provide  management  mechanisms  to  configure  the  required  inter-domain 
routing  information. 
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9     Procedures  for  OSI  Network  Service/Protocol  Identification 
9.1  General 

The  Protocol  Identifiers  specified  in  ISO  TR  9577  ("Protocol  Identification  in  the  OSI  Network  Layer") 
provide  a  basis  from  which  OSI  systems  (both  end  systems  and  intermediate  systems)  may  derive  a  set 
of  procedures  for  indicating  which  OSI  protocols  are  used  in  a  particular  instance  of  communication.  As 
such,  these  procedures  are  only  concerned  with  Initial  Protocol  Identifiers  (IPIs)  and  Subsequent 
Protocol  Identifiers  (SPIs)  that  identify  OSI  protocols  and  pertain  to  the  following  types  of  systems: 

a)  systems  providing/supporting  only  CONS  (using  ISO  8208/8878); 

b)  systems  providing/supporting  only  CLNS  (using  ISO  8473); 

c)  systems  providing/supporting  both  CONS  and  CLNS. 

From  this  set  of  definitions,  the  following  possibilities  for  success  (S)  or  failure  (F)  of  an  instance  of 
communication  can  be  defined,  as  shown  in  the  table  below: 

Table  1  -  End  Systems  Communications 


Originating 

Destination 

End 

System  Type 

End  System  Type 

A 

B 

C 

A 

S 

F 

S 

B 

F 

S 

S 

C 

S 

S 

S 

9.2      Processing  of  Protocol  Identifiers 

The  usage  of  Protocol  Identifiers  in  Network  Protocol  Data  Units  (NPDUs)  depends  on  several  factors: 

a)  the  OSI  Network  Service  to  be  provided; 

b)  the  protocol  to  be  used  in  providing  this  service; 

c)  the  role  the  protocol  is  to  be  used  in  (per  the  Internal  Organization  of  the  Network  Layer); 

d)  the  type  of  subnetwork  to  which  the  system  is  connected. 


9.2.1 


Originating  NPDUs 


The  use  of  a  particular  OSI  Network  Service  depends  on  the  capabilities  of  both  the  origination  and 
destination  end  systems.  It  is  not  the  intent  of  this  clause  to  provide  guidelines  on  how  to  make  this 
choice  except  for  simple  obvious  criteria;  rather,  it  is  intended  only  to  provide  guidance  on  how  to 
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convey  this  choice  to  the  destination  system. 

Where  a  priori  knowledge  exists  in  the  originating  end  system  about  the  capabilities  (with  respect  to  OSI 
Network  Services  available)  of  the  destination  end  system,  it  should  be  used.  This  may  result  in  no 
communication  if  the  two  end  systems  involved  only  provide  Network  Services  of  different  types.  A 
selection  is  required  in  cases  where  both  end  systems  provide  both  types  of  network  services;  this 
selection  is  conveyed  by  the  use  of  the  IP!  and  SPI  (but  the  selection  process  is  an  implementation 
matter).  Alternatively,  where  a  priori  knowledge  does  not  exist,  then  the  selection  of  a  service  to  use  in 
an  instance  of  communication  depends  solely  on  the  capabilities  of  the  originating  end  system  as 
described  below: 

a)  If  only  CONS-related  protocols  (e.g.,  ISO  8208)  are  available,  then  this  should  be  used  and 
the  Protocol  Identifiers  specified  so  as  to  reflect  the  chosen  protocol(s)  and  service; 

b)  If  only  CLNS-related  protocols  (e.g.,  ISO  8473)  are  available,  then  this  should  be  used  and 
the  Protocol  Identifiers  specified  so  as  to  reflect  the  chosen  protocol  (s)  and  service; 

c)  If  both  services  are  available,  then  other  criteria  are  used  in  deciding  which  to  use  in  an 
instance  of  communication. 

NOTE  -  The  choice  of  OSI  Network  Service  to  be  used  in  an  instance  of  communication  is  reflected  in  the 
Network  Service  primitives  issued  by  the  Network  Service  user. 

Once  a  selection  of  Network  Service  has  been  made,  the  use  of  particular  protocols  depend  on,  for 
example,  the  subnetwork  to  which  the  originating  End  System  is  attached.  Some  specific  cases  are 
given  in  Annex  A  of  ISO  TR  9577.  Another  case  involves  use  of  the  Protocol  for  Providing  the 
Connectionless  Network  Service  directly  over  the  Data  Link  Service,  as  given  in  ISO  8473  (e.g.,  in  a 
LAN).  In  this  case,  the  IPI  indicates  ISO  8473. 


9.2.2       Destination  System  Processing 

A  system  receiving  an  NPDU  must  first  be  concerned  with  the  protocol  identified  by  the  IPI.  Valid  values 
are  given  in  table  2  of  ISO  TR  9577.  If  the  protocol  is  recognized  as  one  supported  by  the  system, 
further  processing  of  the  protocol  is  performed  according  to  the  rules  of  that  protocol.  If  not,  an  error  is 
recognized  and  may  be  conveyed  to  the  originating  peer  entity.  With  respect  to  ISO  8208  and  ISO  8473, 
the  following  would  apply  for  such  error  conditions: 

a)  For  ISO  8208,  the  condition  is  classified  as  an  "invalid  General  Format  Identifier,"  for  which  a 
DIAGNOSTIC  packet  may  be  returned.  If  DIAGNOSTIC  packets  are  not  used  by  the  system,  the 
NPDU  is  discarded  without  any  further  action; 

b)  For  ISO  8473,  the  NPDU  is  discarded  without  any  further  action. 

Given  acceptance  of  the  protocol  identified  by  the  IPI,  the  system  must  also  determine  the  acceptability 
of  the  subsequent  protocols  and  OSI  Network  Service  being  requested.  Use  of  ISO  8473  implies  CLNS; 
however,  use  of  ISO  8208  can  imply  either  CONS  or  CLNS,  as  identified  by  the  SPI.  In  the  case  of  ISO 
8208,  therefore,  further  processing  is  needed  to  determine  the  acceptability  of  the  requested 
protocol /service.  If  these  are  not  acceptable  (e.g.,  not  supported  by  the  system),  the  call  should  be 
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cleared  with  a  diagnostic  ccxle  of  "Connection  Rejection  -  unrecognizable  protocol  identifier  in  user  data" 
(decimal  249). 

NOTE  -  In  ISO  8208,  a  call  may  be  refused  for  reasons  other  than  non-support  of  the  requested  OS! 
Network  Service. 


9.2.3       Further  Processing  in  Originating  End  System 

Further  processing  on  receipt  of  an  NPDU  in  response  to  an  initial  attempt  to  communicate  may  be 
necessary/useful  to  determine  the  success  of  such  an  attempt. 

For  ISO  8473,  when  used  directly  over  the  Data  Link  Service,  the  success  or  failure  of  an  attempt  to 
communicate  may  not  be  visible/obvious  within  the  Network  Layer.  On  the  other  hand,  use  of  ISO  8473 
over  ISO  8208  may  provide,  via  the  diagnostic  code  in  a  received  CLEAR  INDICATION  packet,  an 
indication  of  failure  to  communicate  (e.g.,  the  remote  system  does  not  support  CLNS). 

When  using  ISO  8208  to  provide  the  CONS,  the  diagnostic  code  in  a  received  CLEAR  INDICATION 
packet  may  provide  the  necessary  indication  of  why  a  call  was  refused. In  cases  where  an  ISO  8208  call 
is  refused  with  diagnostic  #249,  it  would  not  be  desirable  to  re-attempt  such  calls  with  the  exact  same 
set  of  parameters;  however,  how  the  originating  system  ensures  this  is  a  local  matter. 

In  cases  where  an  originating  system  is  capable  of  supporting  both  OSI  Network  Services,  it  may  wish 
to  re-attempt  communications  using  the  other  mode  of  Network  Service  than  that  initially  attempted. 


9.3      Applicable  Protocol  Identifiers 

The  protocol  identifiers  applicable  to  these  agreements  are  given  in  table  2  and  table  3. 


Table  2  -  IPI  Values 


Bit  Pattern 
87654321 

Protocol 

00001000 
10000001 
10000010 
xxOlxxxx 
xxlOxxxx 
OOllxxxx 

CCITT  I.451/Q.931 

ISO  8473  (excluding  the 

inactive  subset) 

ISO  9542 

ISO  8208/CCITT  X.25-Modulo  8 
ISO  8208/CCITT  X,25-ModulO  128 
ISO  8208/CCITT  X.25-GFI  Extension 
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Table  3  -  SPI  Values 


Bit  Pattern^ 
87654321 

Protocol 

00000000 
thru 

00111111 
10000001 
10000100 

ISO  8073  ADDl/CCITT  X.224 
See  table  4.1 

ISO  8473 

ISO  8878/Annex  A 

NOTES 

1    A  null  SPI  value  (e.g.,  no  Call  User  Data  Field  in  an 
ISO  8208/CCITT  X.25  Call  Request/Incoming  Call  packet) 
shall  indicate  ISO  8073/CCITT  X.224. 

When  using  ISO  8208,  values  other  than  one  of  those  listed  in  table  3  are  outside  the  scope  of  these 
agreements. 


10   Migration  Considerations 

This  clause  considers  problems  arising  from  evolving  OSI  standards  and  implementations  based  on 
earlier  versions  of  OSI  standards. 

Until  there  is  widespread  availability  of  1984  X.25  service,  it  will  be  necessary  for  X.400  systems  to  use 
those  existing  packet-switched  public  data  networks  which  offer  only  pre-1984  X.25  service.  While  1980 
X.25  does  not  provide  the  CONS  as  defined  by  ISO  8348,  there  is  no  implication  of  non-conformance  to 
these  Agreements  resulting  therefrom  for  systems  using  1 980  X.25  to  interchange  data  at  the  Net\A/ork 
Layer,  provided  they  conform  in  all  other  respects. 

This  is  an  exception  to  the  Agreements  for  providing  the  OSI  Network  Service,  granted  temporarily  for 
practical  reasons.  This  exception  will  be  removed  when  it  is  deemed  to  be  no  longer  necessary,  in  the 
judgement  of  the  Workshop.  While  this  provision  is  in  effect,  it  provides  an  alternative  method  of  using 
1980  X.25  to  the  provisions  of  6.2. 
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1 1  Use  of  Priority 

Refer  to  the  Working  Implementation  Agreements  document. 

11.1  Introduction 

Refer  to  the  Working  Implementation  Agreements  document. 

1 1 .2  Overview 

Refer  to  the  Working  Implementation  Agreements  document. 

12  Conformance 

Refer  to  the  Working  Implementation  Agreements  document. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Lower  Layers  Special  Interest  Group 
(LLSIG)  of  the  Open  Systems  Interconnection  Implementors'  Workshop  (OIW).  See  Procedures  Manual  for 
Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above-mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  this  subject. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  4  -  Transport 


0  Introduction 

These  agreements  support  the  integration  of  LANs,  packet  networks,  and  other  WANs  with  the  smallest 
possible  set  of  mandatory  protocol  sets,  in  accordance  with  the  other  agreements  already  reached.  Nothing 
here  shall  preclude  vendors  from  implementing  protocol  suites  in  addition  to  the  ones  described  in  this 
document. 


1  Scope 

This  part  presents  agreements  for  providing  the  OSI  Transport  layer  services  over  both  connection  mode 
and  connectionless  mode  services. 


2     Normative  References 


2.1  CCITT 

[1]  Recommendation  X.214  (Blue  Book,  1988),  Transport  Service  Definition  for  Open  Systems 
Interconnection  for  CCITT  Applications. 

[2]  Recommendation  X.224  (Blue  Book,  1988),  Transport  Protocol  Specification  for  Open  Systems 
Interconnection  for  CCITT  Applications. 

2.2  ISO 

[3]  ISO  8072,  Information  processing  systems  -  Open  systems  interconnection  -  Transport  sen/ice 
defintion. 

[4]  ISO  8072  Addendum  1,  Information  processing  systems  -  Open  systems  interconnection  - 
Addendum  1:  Transport  sen/ice  definition  -  Connectionless-mode  transmission. 

[5]  ISO  8073  Edition  2,  Information  processing  systems  -  Open  systems  interconnection  -  Connection 
oriented  transport  protocol  specification. 

[6]  ISO  8073  Addendum  1,  Information  processing  systems  -  Open  systems  interconnection  - 
Connection  oriented  transport  protocol  specification  -  Addendum  1:  Network  connection 
management  subprotocol. 

[7]  ISO  8073  Addendum  2,  Information  processing  systems  -  Open  systems  interconnection  - 
Connection  oriented  transport  protocol  specification  -  Addendum  2:  Class  four  operation  over 
connectionless  network  sen/ice. 

[8]       ISO  8602,  Information  processing  systems  -  Open  systems  interconnection  -  Protocol  for  providing 
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the  connectionless-mode  transport  service. 
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Status 


Completed  December  1990. 
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Errata 


NOTE  -  This  clause  may  contain  "defect  report"  and  resolutions  material,  and  the  versions  of  implementor 
agreements  to  which  this  material  applies. 


5     Provision  of  Connection  Mode  Transport  Service 

Three  connection  mode  protocol  classes  have  been  identified  for  implementation.  Transport  classes  0, 2  and 
4  of  X.224  (1988)^  have  been  endorsed  for  use  over  CONS.  Only  Transport  Class  4  of  ISO  8073/Add.  2  ^ 
has  been  endorsed  for  use  over  CLNS.  The  following  class  combinations  are  endorsed  for  CONS:  (0),  (0,2) 
or  (0,2,4). 


5.1      Transport  Class  4 


5.1.1       Transport  Class  4  Overview 

Transport  Class  4  is  mandatory  for  communication  between  systems  using  the  OSI  CLNS  and  may  also  be 
used  for  systems  using  the  OSI  CONS  (e.g.,  a  private  MHS,  etc.). 


Where  a  OR  TPDU  proposing  Class  2  or  4  is  initiated.  Class  0  shall  be  explicitly  indicated  as  an 
alternative  class  except  if  there  is  already  one  (or  several)  transport  connection(s)  assigned  to  the 
network  connection  (multiplexing  being  possible). 


i. 


2 


In  general,  references  to  ISO  8073  in  ISO  8073/Add.  2  should  be  interpreted  as  applying  to  X.224 
(1988);  however,  the  reference  to  Clause  14.6.a  in  Clause  14  of  ISO  8073/Add.  2  should  be 
Interpreted  as  a  reference  to  Clause  14.5.a  of  X.224(1988). 
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5.1.2       Protocol  Agreements 

A  disconnect  request  shall  be  issued  In  response  to  a  connect  request  when  the  maximum  number  of 
Transport  connections  Is  reached  or  exceeded. 


5.1.2.1        General  Rules 

The  rules  are  as  follows: 

a)  All  implementations  shall  request  "use  of  extended  formats"  in  the  CR  TPDU.  Implementations 
shall  accept  the  "use  of  extended  formats"  in  the  CC  TPDU  if  it  was  proposed  in  the  CR  TPDU. 
Implementations  shall  accept  "use  of  normal  formats"  if  it  was  proposed  in  the  CR  TPDU; 

b)  Negotiation  of  protection  is  outside  the  scope  of  these  agreements.  If  negotiation  of  protection 
is  not  supported,  receipt  of  the  protection  parameters  in  CR  TPDU  and  CC  TPDU  shall  be  ignored; 

c)  Implementations  shall  be  capable  of  proposing  and  accepting  the  non-use  of  checksums; 

d)  Use  of  the  acknowledgment  time  parameter  is  optional.  If  an  implementation  is  operating  any 
policy  which  delays  the  transmission  of  AK  TPDUs,  the  maximum  amount  of  time  by  which  a  single 
AK  TPDU  may  be  delayed  shall  be  indicated  to  the  peer  Transport  service  provider  using  the 
acknowledgment  time  parameter  The  value  transmitted  should  be  expressed  in  units  of  milliseconds 
and  rounded  up  to  the  nearest  whole  millisecond; 

e)  QoS  negotiation  is  outside  the  scope  of  these  agreements.  If  QoS  negotiation  is  not  supported, 
receipt  of  the  parameters  "throughput,"  "residual  error  rate,"  "priority,"  and  "transit  delay"  in  the  CR 
and  CC  TPDUs  shall  be  ignored; 

f)  It  is  recommended  that  implementations  not  send  user  data  in  the  CR  TPDU  or  the  CC  TPDU. 
The  disposition  of  any  user  data  received  in  a  CR  TPDU  or  CC  TPDU  is  implementation  dependent; 

g)  It  is  recommended  that  implementations  not  send  user  data  in  the  OR  TPDU.  The  disposition 
of  any  user  data  received  in  a  OR  TPDU  is  implementation  dependent; 

h)  An  unknown  parameter  in  any  received  CR  TPDU  shall  be  ignored; 

i)  A  Transport  entity  shall  accept  a  DR  TPDU  and  a  corresponding  DC  TPDU  with  or  without  a 
checksum  in  response  to  a  CR  or  CC  TPDU; 
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j)  Transmitted  DR  TPDUs  shall  carry  a  disconnect  reason  code  which  pertains  to  the  actual  cause 
of  the  disconnect.  A  DR  TPDU  may  carry  a  reason  code  of  "0"  (unspecified)  if  an  appropriate  reason 
code  is  not  defined; 

k)  Known  parameters  with  valid  lengths  but  with  invalid  values  in  a  CR  TPDU  shall  be  handled  as 
follows: 

1)  Parameter:  2)  Action: 

a)  TSAPid  a)  Send  DR  TPDU 

b)  TPDU  size  b)  ignore  parameter,  use  default 
i '       't^n^       c)  Version  c)  ignore  parameter,  use  default 

d)  Checksum  d)  discard  CR  TPDU 

e)  Alternate  Protocol  Classes    e)  Protocol  Error 

I)  Unrecognized  or  not  applicable  bits  of  the  Additional  Options  parameter  shall  be  ignored. 

m)  It  is  recommended  that  the  capability  of  request  acknowledgments  be  supported  and  proposed 
in  CR  TPDUs.  If  request  acknowledgments  are  supported,  then  if  the  implementation  delays 
acknowledgments  it  shall: 

1)  request  use  of  request  acknowledgments  in  the  CR  TPDU; 

2)  accept  the  use  of  request  acknowledgments  in  the  CC  TPDU  if  it  was  proposed  in  the 
CR  TPDU. 

n)  It  is  recommended  that  implementations  send  both  the  preferred  and  existing  TPDU  size 
parameters  in  the  CR  TPDU. 

o)  It  is  recommended  that  inactivity  timer  values  be  exchanged  during  connection  establishment. 
This  may  be  mandatory  in  the  future.  If  the  "exchange  of  inactivity  timers"  capability  is  supported, 
the  implementation  shall  send  its  minimum  inactivity  timer  in  the  CR  TPDU.  If  a  CR  TPDU  is  received 
,  with  this  timer  value  and  the  capability  is  supported,  the  responding  CC  TPDU  shall  contain  the 
inactivity  time. 

If  the  Inactivity  time  is  received  and  the  capability  is  supported,  the  following  shall  be  used  as  an  upper 
bound  for  W: 

Ir/N  >  W        N  ^  2 
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5.1.2.2 


Transport  Class  4  Service  Access  Points  or  Selectors 


If  present,  the  TSAP  Id.  field  in  the  CR  and  CC  TPDUs  shall  be  encoded  as  a  variable  length  field  and  will 
be  interpreted  as  an  octet  string.  The  length  of  the  string  cannot  exceed  32  octets. 


It  is  recommended  that  the  value  used  for  the  retransmission  timer  be  based  upon  the  round-trip  delay 
experienced  on  a  transport  connection.  The  implementation  should  maintain,  and  continually  update,  an 
estimate  of  the  round-trip  delay  for  the  TC.  From  this  estimate,  a  value  for  the  retransmission  timer  is 
calculated  each  time  it  is  started.  Example  techniques  for  maintaining  the  estimate  and  calculating  the 
retransmission  timer  are  described  below.  Example  1  represents  a  simple  retransmission  strategy  and 
example  2  is  particularly  suitable  for  networks  subject  to  high  traffic  loads. 


The  value  of  the  retransmission  timer  may  be  calculated  according  to  the  following  formula: 
T1  < —  kE  +  AR. 

In  this  formula,  E  is  the  current  estimate  of  the  round-trip  delay  on  the  transport  connection,  AR  is  the  value 
of  the  acknowledgment  time  parameter  received  from  the  remote  transport  service  provider  during 
connection  establishment,  and  k  is  some  locally  administered  factor. 

A  value  for  k  should  be  chosen  to  keep  the  retransmission  timer  sufficiently  small  such  that  lost  TPDUs  will 
be  detected  quickly,  but  not  so  small  that  false  alarms  are  generated  causing  unnecessary  retransmission. 

The  value  of  E  may  be  calculated  using  an  exponentially  weighted  average  based  upon  regular  sampling 
of  the  interval  between  transmitting  a  TPDU  and  receiving  the  corresponding  acknowledgment.  Samples  are 
taken  by  recording  the  time  of  day  when  a  TPDU  requiring  acknowledgment  is  transmitted  and  calculating 
the  difference  between  this  and  the  time  of  day  when  the  corresponding  acknowledgment  is  received.  New 
samples  are  incorporated  with  the  existing  average  according  to  the  following  formula: 

E  <_  E  +  (1  -  a)(S  -  E). 

In  this  formula,  S  is  the  new  sample  and  o  is  a  parameter  which  can  be  set  to  some  value  between  0  and 
1 .  The  value  chosen  for  a  determines  the  relative  weighting  placed  upon  the  current  estimate  and  the  new 
sample.  A  large  value  of  o  weights  the  old  estimate  more  heavily  causing  it  to  respond  only  slowly  to 
variations  in  the  round-trip  delay.  A  small  value  weights  the  new  sample  more  heavily  causing  a  quick 
response  to  variations.  (Note  that  setting  a  to  1  will  effectively  disable  the  algorithm  and  result  in  a  constant 
value  for  E,  being  that  of  the  initial  seed.) 

If  a  is  set  to  1-2  "  for  some  value  of  n,  the  update  can  be  reduced  to  a  subtract  and  shift  as  shown  below: 
E  < —  E  +  2  "  (S  -  E). 

When  sampling,  if  an  AK  TPDU  is  received  which  acknowledges  multiple  DT  TPDUs,  only  a  single  sample 
should  be  taken  being  the  round-trip  delay  experienced  by  the  most  recently  transmitted  DT  TPDU.  This 


5.1.2.3 


Retransmission  Timer 


Example  1 
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attempts  to  minimize  in  tiie  sample  any  delay  caused  by  the  remote  transport  service  provider  withholding 
AK  TPDUs. 

Example  2 

As  network  load  increases,  the  variability  of  round-trip  delay  also  increases,  in  environments  where  load 
fluctuates  widely,  it  is  therefore  useful  to  estimate  the  variability  of  round-trip  delay  measurements  and  use 
this  estimate  in  the  calculation  of  retransmission  timer  values.  An  estimate  of  the  variability  of  round-trip 
delay  measurements  can  be  efficiently  calculated  as  an  exponentially  weighted  average  of  the  differences 
between  round-trip  delay  measurements  and  the  average  round-trip  delay.  This  represents  the  mean 
deviation  of  the  round-trip  delays,  which  is  a  useful  approximation  of  the  standard  deviation  and  can  be 
much  more  efficiently  computed.  The  formula  is 

D  <~  D  +  (1  -a)(|S  -  E|  -  D) 

where  D  is  the  estimate  of  variability  in  round-trip  delays.  S,  E,  and  a  are  as  defined  for  the  preceding 
formula.  As  before  the  value  of  a  must  be  between  0  and  1  and  the  choice  of  a  value  of  1  -  2  ^^  allows  for 
efficient  update  of  the  average.  The  value  of  a  for  the  variability  estimation,  though,  does  not  need  to  be  the 
same  as  that  used  for  the  round-trip  delay  estimate.  A  smaller  value  for  a  is  useful  in  the  variability  estimation 
to  cause  a  more  rapid  response  to  changes  in  round-trip  delays.  D  can  then  be  used  to  calculate 
retransmission  timer  values  according  to  the  formula: 

T1  <~  E  +  AR  +  kD 

where  T1  is  the  retransmission  timer  value,  E  is  the  estimated  average  round-trip  delay,  AR  is  the  value  of 
the  acknowledgment  timer  parameter  received  from  the  remote  transport  service  provider  during  connection 
establishment,  and  /(  is  a  locally  administered  factor.  Since  D  approximates  the  standard  deviation  of  the 
round-trip  delays,  but  is  greater  than  or  equal  to  the  standard  deviation,  round-trip  delays  within  k  standard 
deviations  of  the  mean  would  be  accounted  for  by  the  retransmission  timer  value  (e.g.,  /(  =  2,  if  round-trip 
delays  were  normally  distributed,  would  account  for  95%  of  the  variability). 

Round-trip  time  measurements  based  on  acknowledgment  of  any  retransmitted  data  should  not  be  used  to 
update  the  round-trip  delay  estimate  or  the  estimate  of  variability.  Such  measurements  are  not  reliable  since 
it  is  ambiguous  which  transmission  of  the  data  is  being  acknowledged. 

One  strategy  for  handling  a  retransmission  timeout  is  to  retransmit  the  PDU  and  reset  the  timer  with  a  value 
that  is  twice  the  previous  value.  In  this  case,  a  new  roundtrip  delay  estimate  and  estimate  of  variability 
should  be  calculated  only  when  an  acknowledgment  of  data  is  received  where  none  of  the  acknowledged 
data  has  been  retransmitted.  This  calculation  uses  the  new  round-trip  delay  measurement  and  the  last 
estimate  before  the  retransmission  timeout(s). 


5.1.2.4        Keep-Alive  Function 

The  Class  4  protocol  detects  a  failed  Transport  connection  by  use  of  an  "inactivity  timer."  This  timer  is  reset 
each  time  a  TPDU  is  received  on  a  connection.  If  the  timer  ever  expires,  the  connection  is  terminated. 

The  Class  4  protocol  maintains  an  idle  connection  by  periodically  transmitting  an  AK  TPDU  upon  expiration 
of  the  "window  timer."  Thus,  in  a  simple  implementation,  the  interval  of  one  transport  entity's  window  timer 
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must  be  less  than  that  of  its  peer's  inactivity  timer,  and  vice  versa.  The  following  agreements  permit 
communicating  transport  entities  to  maintain  an  idle  connection  without  shared  information  about  timer 
values: 


a)  In  accordance  with  ISO  8073/X.224,  Clause  12.2.3.9.a,  all  implementations  must  respond  to  the 
receipt  of  a  duplicate  AK  TPDU  not  containing  FCC  by  transmitting  an  AK  TPDU  containing  the  "flow 
control  confirmation"  parameter; 

b)  Implementations  must  always  transmit  duplicate  AK  TPDUs  without  FCC  on  expiration  of  the 
local  window  timer  (see  ISO  8073/X.224,  Clause  12.2.3.8.1).  Receipt  of  this  TPDU  by  the  remote 
Transport  entity  will  cause  it  to  respond  with  an  AK  TPDU  containing  the  "flow  control  confirmation" 
parameter.  When  this  is  received  by  the  local  transport  entity,  it  will  reset  its  inactivity  timer.  See 
figure  1 ; 

c)  It  is  a  local  matter  for  an  implementation  to  set  the  intervals  of  its  timers  to  appropriate  relative 
values.  Specifically: 

1)  The  window  timer  must  be  greater  than  the  round-trip  delay.  See  5.1.2.3; 

2)  The  inactivity  timer  must  be  greater  than  two  times  the  window  timer;  and  should 
normally  be  an  even  greater  multiple  if  the  Transport  connection  is  to  be  resilient  to  the  loss 
of  an  AK  TPDU. 


A  duplicate  AK  TPDU  (see  figure  1)  is  one  which  contains  the  same  values  for  YR-TU-NR,  credit,  and 
subsequence  number  as  the  previous  AK  TPDU  transmitted.  A  duplicate  AK  TPDU  does  not  acknowledge 
any  new  data,  nor  does  it  change  the  credit  window. 


reset 


reset 


expire 


expi re 


W 


expire 


Figure  1  -  AK  exchange  on  idle  connection. 
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5.1.2.5        Congestion  Avoidance  Policies 

This  clause  defines  both  mandatory  and  optional  requirements  relating  to  avoiding  congestion  in  OSI 
networks  and  recovering  from  it  when  it  is  experienced.  The  mandatory  requirements  specify  a  minimum 
approach  to  congestion  avoidance/recovery  which  can  be  tuned  based  upon  the  specific  requirements  of 
the  network.  The  optional  requirements  specify  a  dynamic  window  sizing  scheme  which,  if  implemented,  will 
contribute  further  to  the  avoidance  of  congestion  in  the  network. 

Mandatory  Requirements  are  as  follows: 

a)  A  maximum  size  for  the  "receive  credit  window,"  the  value  of  which  is  locally  configurable,  should 
be  provided.  A  "receive  credit  window"  reflects  the  number  of  credits  sent  by  a  Transport  entity  for 
a  Transport  connection.  The  maximum  size  of  the  "receive  credit  window"  shall  be  referred  to  as 
WR,; 

b)  A  maximum  size  for  the  "sending  credit  window,"  the  value  of  which  is  locally  configurable,  shall 
be  provided.  A  "sending  credit  window"  reflects  the  number  of  data  TPDUs  that  a  Transport  entity 
is  willing  to  send  on  a  Transport  connection.  The  maximum  size  of  the  "sending  credit  window"  shall 
be  referred  to  as  WS,.  As  specified  in  ISO  8073,  the  "sending  credit  window"  shall  also  be  less  than 
or  equal  to  the  remote  "receive  credit  window"  as  conveyed  in  the  last  CDT  field; 

c)  It  is  strongly  recommended  that  an  implementation  use  a  retransmission  timer  per  Transport 
connection.  If,  upon  expiration  of  the  retransmission  timer,  an  implementation  allows  more  than  "1" 
TPDU  to  be  transmitted  a  means  to  locally  adjust  the  maximum  number  shall  be  provided; 

d)  All  implementations  shall  have  the  capability  of  operating  without  delaying  ACKs  of  data  TDPUs 
V      received  in-sequence  (i.e.,  Al  essentially  equals  zero).  If  an  implementation  optionally  chooses  to 

explicitly  delay  ACKs,  a  means  to  locally  adjust  Al  shall  be  provided. 

Optional  Requirements  are  as  follows: 

For  systems  implementing  the  dynamic  window  sizing  scheme  the  following  rules  apply  as  described  below: 

1.  RECEIVING  TRANSPORT  ENTITY  (RTE)  RULES: 

a)  Rule  1  -  Initialization  of  Window: 

1)  The  initial  value  of  WR  (known  as  WRq)  shall  have  a  locally  configurable  upper  bound. 
This  window  is  sent  to  the  sending  transport  entity  (STE)  in  the  next  CDT  field  transmitted; 

a)  Rule  2  -  Required  Sampling  Period: 

1)  All  PTEs  shall  maintain  a  fixed  value  for  WR  until  the  next  2WR  DT 
TPDU  arrive  since  the  last  CDT  field  was  transmitted  by  the  RTE; 

b)  Rule  3  -  Required  Counting  of  Received  TPDUs  in  a  Sampling  Period: 

1)  All  PTEs  shall  maintain  a  count,  N,  equal  to  the  total  number  of  TPDUs 
received  and  a  count,  NC,  equal  to  the  total  number  of  TPDUs  received 
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which  had  the  CE  Flag  set.  All  types  of  TPDUs  are  Included  in  the  counts 
for  N  and  NC,  not  just  DT  TPDUs; 

c)  Rule  4  -  Required  Action  upon  the  end  of  a  Sampling  Period:  All  RTEs  shall  take 
the  following  actions  at  the  end  of  each  sampling  period: 

1)  If  the  count  NC  is  less  than  50  percent  of  the  count  N,  the  RTE  shall 
Increase  WR  by  adding  1  up  to  a  maximum,  WR,,  (that  is  based  on  the 
local  buffer  management  policy);  otherwise,  it  shall  decrease  WR  by 
multiplying  by  0.875  (a  minimum  of  1); 

2)  Reset  N  and  NC  to  zero; 

3)  Transmit  the  new  window  WR  in  the  next  CDT  field  sent  to  the  sending 
transport  entity; 

2)  SENDING  TRANSPORT  ENTITY  (STE)  RULES: 

a)  Rule1:       Initialization  of  Window: 

1)  All  STEs  shall  maintain  a  sending  window  size  (WS).  Initially  and  also 
as  long  as  there  is  no  loss,  WS  is  set  equal  to  the  receiving  window  value 
WR  received  from  the  remote  RTE  in  the  last  CDT  field; 

b)  Rule  2:       Required  Action  on  a  Timeout; 

1)  All  STEs  shall  reset  WS  to  one  when  the  retransmissions  timer  expires 
and  indicates  a  lost  TPDU.  WS  now  limits  the  number  of  DT  TPDUs  that 
may  be  transmitted  or  retransmitted  without  further  acknowledgments; 

c)  Rule  3:        Required  Counting  of  Acknowledged  TPDU: 

1)  All  STEs  shall  maintain  a  count,  ACKRCVD  of  the  number  of  DT  TPDUs 
acknowledged,  by  the  RTE,  since  WS  was  last  adjusted.  Therefore  each 
time  WS  is  adjusted,  the  count  ACKRCVD  shall  be  reset  to  zero; 

d)  Rule  4:       Increase  Window  Policy: 

1)  All  STEs  shall  increase  WS  by  one  each  time  ACKRCVD  is  equal  to  or 
greater  than  the  current  value  of  WS,  unless  WS  exceeds  the  window 
permitted  by  the  remote  RTE. 


5.1 .2.6        Use  of  Priority 

(Refer  to  the  Working  Implementation  Agreements). 
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5.2.1 


Transport  Class  0  Overview 


Transport  Class  0  over  X.25  is  mandatory  (see  X.400)  for  use  in  communicating  witli  public  MHS  systems 
operating  in  accordance  with  the  CCITT  X.400  series  recommendations.  The  purpose  of  the  agreements 
concerning  Transport  Class  0  is  to  allow  connection  to  these  public  services.  Transport  Class  0  over  X.25 
can  also  be  used  in  communicating  between  PRMDs  (this  choice  is  prevalent  outside  North  America). 


Transport  Class  0  agreements  are  as  follows: 

a)  The  Error  (ER)  TPDU  may  be  used  at  any  time  and  upon  receipt  requires  that  the  recipient 
disconnect  the  network  connection,  and  by  extension  the  transport  connection; 


b)  The  allowed  values  for  the  maximum  TPDU  size  are  128,  256,  512,  1024,  and  2048; 

c)  The  Class  0  protocol  does  not  support  multiplexing.  At  any  instant,  one  Transport  corresponds 
to  one  Network  connection; 

d)  It  is  recommended  that  the  optional  timers  TSl  and  TS2,  if  implemented,  be  settable  by  local 
system  management.  Values  in  the  order  of  minutes  should  be  supported; 

e)  An  unlimited  TSDU  length  must  be  supported. 

V    ,  :    f)    It  is  recommended  that  implementations  send  both  the  preferred  and  existing  TPDU  size 
parameters  in  the  CR  TPDU. 

5.2.2.2        Transport  Class  0  Service  Access  Points 

For  communicating  with  public  MHS  systems,  section  5  of  X.410  specifies  the  use  and  format  of  TSAP 
identifiers. 

5.2.3       Rules  for  Negotiation 

The  rules  for  class  negotiation  shall  be  used. 


5.2.2 


Protocol  Agreements 


5.2.2.1 


General  Rules 
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5.3.1  Transport  Class  2  Overview 

Transport  Class  2  is  applicable  in  OSI  end  systems  which  provide  the  Connection-mode  Network  Sen/ice. 

5.3.2  Protocol  Agreements 

Transport  Class  2  agreements  follow: 

a)  The  values  of  the  TS1  and  TS2  timers  shall  be  configurable.  The  recommended  timer  values  are: 

1)  TS1:  60  seconds; 

2)  TS2:  60  seconds; 

b)  If  present,  the  TSAP-id  field  in  the  CR  and  CC  TPDUs  shall  be  encoded  as  a  variable  length  field 
and  will  be  interpreted  as  an  octet  string.  The  length  of  the  string  cannot  exceed  32  octets; 

c)  The  rules  for  class  negotiation  shall  be  used; 

d)  QoS  negotiation  is  outside  the  scope  of  these  agreements.  If  QoS  negotiation  is  not  supported, 
receipt  of  the  parameters  "throughput,"  "residual  error  rate,"  "priority,"  and  "transit  delay"  in  the  CR 
and  CC  TPDU  shall  be  ignored. 

NOTE  -  If  Class  0  is  indicated  in  the  Alternative  Protocol  Class  field  and  QoS  parameters  are  conveyed  and 
the  responding  end  system  chooses  Class  0,  then  the  QoS  parameters  have  been  ignored  by  the  responding 
system. 

e)  It  is  recommended  that  implementations  send  both  the  preferred  and  existing  TPDU  size 
parameters  in  the  CR  TPDU. 

6     Provision  of  Connectionless  Transport  Service 

ISO  8072/Add.  2  is  the  Transport  Service  Definition  covering  Connectionless-mode  Transmission.  ISO  8602 
is  the  Protocol  for  providing  the  Connectionless-Mode  Transport  Service. 


) 
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6.1      Connectionless  Transport  Overview 

When  providing  tfie  connectionless  Transport  Service,  the  protocol  shall  be  implemented  as  specified  in  ISO 
8602. 


6.2      Protocol  Agreements 


6.2.1        General  Rules 

The  connectionless  Transport  protocol  is  a  relatively  simple  protocol  providing  little  opportunity  for 
conflicting  interpretations.  A  few  relevant  agreements  follow: 

a)  The  optional  elements  of  procedure  for  use  of  CLTS  over  CONS  (i.e.,  clause  6.3  of  ISO  8602) 
will  not  be  supported; 

b)  A  Unitdata  TPDU  that  is  received  that  contains  a  protocol  error  or  an  unknown  destination  TSAP 
.ji.:.;  ji    ID  shall  be  discarded. 


6.2.2       Connectionless  Transport  Service  Access  Points  or  Selectors 

The  TSAP  selector  field  in  the  UD  TPDU  shall  be  encoded  as  a  variable  length  field  and  will  be  interpreted 
as  an  octet  string.  The  length  of  the  string  cannot  exceed  32  octets. 


7     Transport  Protocol  Identification 

The  absence  of  Call  User  Data  (CUD)  in  an  X.25/ISO  8208  Call  Request/Incoming  Call  packet  indicates  the 
operation  of  ISO  8073/CCITT  X.224. 

Protocol  Identification  TPDU  values  applicable  to  these  agreements  are  given  in  table  1 .  These  TPDUs,  when 
used,  are  conveyed  as  N-connect  user  data. 


Table  1  -  Protocol  Identification  TPDU  Values 


TPDU  Value 

Protocol 

03     01    01    00  * 
(see  note  1) 
03     01    02    00  ** 
(see  note  2) 

ISO  8073/Adcl.  1 
ISO  8602 

NOTES 
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1  Corresponds  to  an  ISO  8073/Add.  1  UN-TPDU  and  a  X.224  Annex  B  PI-TPDU. 

2  Corresponds  to  an  ISO  8073/Add.  1  UN-TPDU. 
The  following  agreements  apply: 

a)  Any  additional  TPDU,  which  follows  (by  concatenation)  a  Protocol  Identification  TPDU  shall  be 
ignored  if  ISO  8073/Add.  1  is  not  supported; 

b)  When  using  ISO  8208,  usage  of  a  Protocol  Identification  TPDU  not  corresponding  to  those  listed 
in  table  1  is  outside  the  scope  of  these  agreements. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Upper  Layers  Special  Interest 
Group  (ULSIG)  of  the  Open  Systems  Interconnection  Implementors'  Workshop  (OIW).  The  charter  for  the 
OIW  is  located  in  the  Procedures  Manual. 

The  text  in  this  part  has  been  approved  by  the  Plenary  of  the  OIW.  This  part  replaces  the  previously 
existing  part  on  the  Upper  Layers. 

Annex  B  is  for  information  purposes  only.  Annex  A  forms  an  integral  part  of  these  Implementor 
Agreements. 

Future  changes  and  additions  to  these  Implementor  Agreements  will  be  published  as  change  pages. 
Deleted  and  replaced  text  will  be  shown  as  struck.  New  and  replacement  text  will  be  shown  as  shaded. 
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Part  5  -  Upper  Layers 


0  Introduction 

In  this  portion  of  tlie  Implementors'  Agreements,  the  Upper  Layers  SIG  is  primarily  concerned  with 
providing  implementation  agreements  for  ACSE,  ROSE,  RISE,  and  the  Presentation  and  Session  layers, 
so  that  systems  implemented  according  to  these  agreements  can  successfully  interoperate. 


1  Scope 

The  agreements  in  this  part  apply  to  all  ASE  agreements  in  this  document.  Each  ASE  SIG  chooses 
which  protocols,  functional  units,  application  contexts,  and  parameters  it  requires.  These  must  be  listed 
in  the  "Specific  ASE  Requirements"  clause  of  this  part.  "  " 


2     Normative  References 


2.1      Session  Layer 

[1]       ISO  8326:  1987  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Connection  Oriented  Session  Sen/ice  Definition. 

[2]       ISO  8327:  1987  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  Basic 
Connection  Oriented  Session  Protocol  Specification. 

[3]       ISO/IEC  JTC1  /SC21  N2494,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Basic  Connection  Oriented  Session  Service  Definition-AD  2  to  ISO  8326  to  Incorporate 
Unlimited  User  Data. 

[4]       ISO/IEC  JTCI  /SC21  N2495,  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Basic  Connection  Oriented  Session  Protocol  Specification  -  AD  2  to  ISO  8327  to  Incorporate 
Unlimited  User  Data. 

[5]       IS0/AD3  8326,  Information  Processing  Systems  -  Open  Systems  Interconnection-Session 
Service  Definition:  Addendum  3  Covering  Connectionless-Mode  Session  Service. 

[6]       ISO/IS  9548,  Information  Processing  Systems  -  Open  Systems  Interconnection-Connectionless 
Session  Protocol  to  Provide  the  Connectionless-t\/lode  Session  Service. 
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2.2  Presentation  Layer 

[7]       ISO  8822:  1988  (ISO/IEC  JTC1/SC21  N2335),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Connection-Oriented  Presentation  Sen/ice  Definition. 

[8]       ISO  8823:  1988  (ISO/IEC  JTC1/SC21  N2336),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Connection  Oriented  Presentation  Protocol  Specification. 

[9]       ISO  8824:  1990  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Specification  of  Abstract  Syntax  Notation  One  (ASN.  1). 

[10]      ISO  8825:  1990  (E),  Information  Processing  Systems  -  Open  Systems  Interconnection  - 
Specification  of  Basic  Encoding  Rules  for  Abstract  Syntax  Notation  One  (ASN.  1). 

[11]      IS0/DAD1  8822:  1989-02-1 5(e)  (ISO/IEC  JTC1/SC21  N  3171),  Information  Processing  Systems  - 
Open  Systems  Interconnection  -  Presentation  Service  Definition:  Draft  Addendum  1  Covering 
Connectionless-Mode  Presentation  Sen/ice. 

[12]      ISO/IS  9576:  1989-02-25  5(E)  (ISO/IEC  JTC1/SC21  N  3172),  Information  Processing  Systems  - 
Open  Systems  Interconnection  -  Connectionless  Presentation  Protocol  to  Provide  ttie 
Connectionless-Mode  Presentation  Service. 

2.3  Application  Layer 

[13]      ISO/DP  9545,  ISO/TC97/SC21/N1743.  July  24,  1987,  revised  November  1987.  Information 
Processing  Systems  -  Open  Systems  Interconnection  -  Application  Layer  Structure. 

2.4  Application  Layer  ■  ASE/ACSE 

[14]      ISO  8649:  1987  (E)  (ISO/IEC  JTCl /SC21  N2326),  Information  Processing  Systems  -  Open 
Systems  Interconnection  -  Sen/ice  Definition  for  the  Association  Control  Sen/ice  Element. 

[15]      ISO  8650:  1987  (E)  (ISO/IEC  JTC1/SC21  N2327),  Information  Processing  Systems  -  Open 

Systems  Interconnection  -  Protocol  Specification  for  the  Association  Control  Service  Element. 

[16]      ISO  8649/DAD2,  Information  Processing  System  -  Open  Systems  Interconnection  -  ACSE 
Service  Definition:  Draft  Addendum  2  Covering  Connectionless-Mode  ACSE  Service. 

[17]     ISO  8649/DAD1  (ISO/IEC  JTC1/SC21  N3771),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Sen/ice  Definition  for  the  Association  Control  Sen/ice  Element  -  Addendum  1 : 
Peer-Entity  Authentication  During  Association  Establishment 

[18]     ISO  8650/DAD1  (ISO/IEC  JTC1/SC21  N3772),  Information  Processing  Systems  -  Open  Systems 
Interconnection  -  Protocol  Specification  for  the  Association  Control  Sen/ice  Element  - 
Addendum  1 :  Peer-Entity  Authentication  During  Association  Establishment 
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[19]  ISO  8649/Cor.1:  1991  (E)  (ISO/IEC  JTC1/SC21  N5630),  Information  Processing  Systems  -  Open 
Systems  Interconnection  -  Technical  Corrigendum  1  to  ACSE  Service  (ISO  8649:  1988)  Covering 
Defects  8649/001,  8649/002  and  8649/003. 

[20]      ISO  8650/Cor.1:  1991  (E)  (ISO/IEC  JTC1/SC21  N5631),  Information  Processing  Systems  -  Open 
Systems  Interconnection  -  Technical  Corrigendum  1  to  ACSE  Protocol  (ISO  8650:  1988) 
Covering  Defects  8650/001 ,  8649/004. 

[20]      ISO  IS  10035:  1989-02-25  (ISO/IEC  JTC1/SC21  N  3456),  Information  Processing  Systems  - 

Open  Systems  Interconnection  -  Connectionless  ACSE  Protocol  to  Provide  the  Connectionless- 
Mode  ACSE  Service. 


3  Status 

This  text  is  stable. 

NOTE  -  Changes  due  to  errata  are  summarized  in  clause  4 


4  Errata 


4.1      ISO  Defect  Solutions 

This  clause  lists  the  defect  solutions  from  ISO  which  are  currently  recognized  to  be  valid  for  the 
purposes  of  conformance. 

ISO  8326  defect  solutions: 

023,  024 
ISO  8327  defect  solutions: 

037,  038 


4.2      Session  Defect  Solutions  Correcting  CCITT  X.215  and  X.225 

The  following  approved  defect  solutions  have  been  integrated  into  the  current  revisions  of  ISO  8326  and 
ISO  8327,  but  are  not  part  of  CCITT  X.215  and  X.225  (1984).  The  defect  solutions  must  be  incorporated 
into  CCITT  Session  to  insure  conformance  with  ISO  Session. 

ISO  8326  defect  solutions: 


004,  006,  007,  009,  Oil,  012,  013,  014,  015,  016,  017,  020. 
ISO  8327  defect  solutions: 
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001,  003,  004,  005,  006,  007,  008,  009,  010,  012,  017,  018,  019,  026,  027,  030,  034,  035. 


4.3      Approved  Errata 

Errata  to  this  part  are  marked  with  change  bars;  deleted  text  is  marked  with  strikeouts  and  new  text  is 
indicated  by  shading. 

5     Association  Control  Service  Element 

5.1  Introduction 

This  clause  details  the  implementation  requirements  for  the  Association  Control  Sen/ice  Element  (ACSE) 
of  the  Application  layer  as  defined  in  ISO  8649  and  ISO  8650. 

5.2  Services 

All  ACSE  services  are  within  the  possible  scope  of  a  workshop-conformant  system. 

5.3  Protocol  Agreements 

5.3.1  Application  Context 

Values  for  and  uses  of  Application  Context  names  are  determined  by  specific  ASEs.  Values  used  by 
ASE  SIGS  are  listed  in  the  clause  entitled  "Specific  ASE  Requirements." 

5.3.2  AE  Title 

AE-titles  shall  be  implemented  as  specified  in  ISO  8650/  Corr.1. 

5.3.3  Peer  Entity  Authentication 

If  supported,  peer-entity  authentication  during  association  establishment  shall  be  implemented  as 
specified  in  Addendum  1  to  ISO  8650  (ISO  8650/DAD1). 
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5.4  ASN.1  Encoding  Rules 

When  the  ABRT  APDU  is  used  during  the  connection  establlshnnent  phase,  Presentation  layer  negotiation 
is  considered  to  be  complete,  and  the  "direct-reference"  component  of  EXTERNAL  shall  not  be  present. 

5.5  Connectionless 

The  connectionless  ACSE  protocol  shall  be  implemented  as  specified  in  ISO  DIS  10035. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 
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ROSE 


ROSE  shall  be  implemented  as  specified  in  ISO  DIS  9072-1.2  and  ISO  DIS  9072-2.2. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 


RISE  shall  be  implemented  as  specified  in  ISO  9066-1  and  ISO  9066-2. 

No  further  agreements  beyond  those  specified  elsewhere  In  this  part  have  been  made  regarding  this 
standard. 


8  Presentation 


8.1  introduction 

This  clause  details  the  implementation  requirements  for  the  Presentation  layer  as  defined  in  the 
Presentation  Service  Definition,  ISO  8822,  and  the  Presentation  Protocol  Definition,  ISO  8823. 

The  task  of  the  Presentation  layer  is  to  carry  out  the  negotiation  of  transfer  syntaxes  and  to  provide  for 
the  transformation  to  and  from  transfer  syntaxes.  The  transformation  to  and  from  a  particular  transfer 
syntax  is  a  local  implementation  issue  and  is  not  discussed  within  this  clause.  This  clause  is  concerned 
with  the  protocol  agreements,  and  thus  is  entirely  devoted  to  the  issues  involved  with  the  negotiation  of 
transfer  syntaxes  and  the  responsibilities  of  the  Presentation  protocol. 

8.2  Service 

Only  the  Kernel  functional  unit  need  be  supported.  The  Context  Management  and  Context  Restoration 
functional  units  are  outside  the  scope  of  these  agreements. 

The  requirement  that  the  Presentation  kernel  functional  unit  be  implemented  does  not  imply  that  any  of 
the  Session  functional  units  for  expedited  data,  typed  data,  and  capability  data  and  the  corresponding 
Presentation  service  primitives  are  required  to  be  implemented. 
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8.3      Protocol  Agreements 


8.3.1       Transfer  Syntaxes 

The  following  transfer  syntax  must  be  supported  for  all  mandatory  abstract  syntaxes:  the  basic  encoding 
rules  for  ASN.1.  This  syntax  is  derived  by  applying  the  b)asic  encoding  rules  for  ASN.1  to  the  abstract 
syntax  (see  the  Basic  Encoding  Rules  for  ASN.1,  ISO  8825). 

The  number  of  transfer  syntaxes  proposed  is  dependent  upon  the  recognized  transfer  syntaxes  which 
are  available  to  support  the  particular  abstract  syntaxes  used  by  an  Application  Entity. 


8.3.2       Presentation  Context  identifier 

A  conformant  implementation  shall  encode  Presentation  context  identifiers  in  the  range  0  to  32,767. 
Implementations  must  be  able  to  handle  a  minimum  of  two  Presentation  contexts  per  connection. 


8.3.3       Default  Context 

If  the  Presentation  expedited  data  service  is  required,  the  default  context  must  be  explicitly  present  in  the 
P-CONNECT  PPDU  at  Presentation  connect  time. 


8.3.4  P-Selectors 

Local  P-selectors  shall  be  a  maximum  of  four  octets.  This  applies  only  to  P-selectors  in  PPDUs  whose 
receipt  by  a  workshop-conformant  system  normally  results  in  either  a  P-CONNECT  indication  or  a  P- 
CONNECT  confirmation  being  issued. 


8.3.5       Provider  Abort  Parameters 

No  conformance  requirements  are  implied  by  the  use  of  either  the  Abort-reason  or  the  Event-identifier 
component  of  the  ARP-PPDU.  The  decision  to  include  these  parameters  is  left  up  to  the  implementation 
issuing  the  abort. 


8.3.6       Provider  Aborts  and  Session  Version 

The  Presentation  Provider  Abort  PPDU  (ARP-PPDU)  shall  be  present  regardless  of  the  Session  version  in 
effect  for  a  given  association.  This  precludes  the  use  of  indefinite  length  encoding  of  an  ARP-PPDU 
when  Session  Version  1  is  in  effect. 
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8.3.7  CPC-Type 

Implementations  shall  not  use  any  CPC-type  values  In  the  SS-user  data  parameter  of  the  S-CONNECT 
unless  more  than  one  transfer  syntax  Is  proposed  for  a  single  Presentation  context  of  the  Presentation 
data  values.  Each  CPC-type  represents  a  unique  transfer  syntax,  so  if  more  than  one  transfer  syntax  is 
proposed,  CPC-type  values  may  appear  in  that  SS-user-data  parameter. 

For  a  Presentation  context  for  which  the  Basic  Encoding  Rules  are  a  proposed  transfer  syntax,  all  PDVs 
in  the  user  data  parameter  of  the  CP  PPDU  must  be  encoded  first  using  the  Basic  Encoding  Rules  and 
must  be  examined  by  the  receiving  Presentation  protocol  machine.  Following  CPC-type  values  may  be 
examined  or  ignored  at  the  receiver's  option  (see  ISO  8823,  clause  6.2.5.3). 


8.3.8  Presentation-context-definition-result-list 

No  semantics  are  implied  by  the  absence  of  the  optional  Presentation-context-definition-result-list 
component  of  the  CPR-PPDU.  This  component  is  required  if  the  Provider-reason  is  absent  in  the  CPR- 
PPDU.  If  the  Provider-reason  is  present,  then  the  Presentation-context-definition-result-list  is  optional. 


8.3.9  RS-PPDU 

The  Presentation-context-identifier-list  shall  not  be  present  when  only  the  kernel  functional  unit  is  in 
effect. 


8.4      Presentation  ASN.1  Encoding  Rules 

If  a  received  PPDU  contains  any  improperly  encoded  data  values  (including  data  values  embedded 
within  the  User  Data  field  of  a  PPDU)  and  an  abort  is  issued,  then  either  an  ARU  or  an  ARP  shall  be 
issued. 


8.5  General 

A  Presentation  data  value  (PDV)  is  a  value  of  a  type  in  an  abstract  syntax,  e.g.,  a  value  of  an  ASN.1 
type. 

A  PDV  may  contain  embedded  PDVs  in  different  contexts.  A  change  of  context  within  a  PDV  is  indicated 
by  an  EXTERNAL  EXTERNAL  implies  an  embedded  PDV. 

A  PDV  cannot  be  split  across  PDV-lists  in  fully-encoded  user  data. 

Fully-encoded-data  that  is  a  series  of  PDVs  in  the  same  Presentation  context  (e.g.,  grouped  FTAM 
PDUs)  shall  be  encoded  either  as  a  single  PDV-list  (using  the  octet-aligned  choice)  or  as  a  series  of 
PDV-lists,  each  encoding  either  a  single  PDV  (using  the  single-ASNI-type  choice)  or  multiple  PDVs 
(using  the  octet-aligned  choice).  Note  that  receivers  must  accept  any  of  the  above  encodings. 
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The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  be  present  In  a  CP  PPDU  if  and  only  If 
more  than  one  transfer  syntax  name  was  proposed  for  the  Presentation  context  of  the  Presentation  data 
values.  The  Transfer-syntax-name  component  of  a  PDV-llst  value  shall  always  be  present  in  a  CPC-type. 
If  only  the  Kernel  functional  unit  is  negotiated,  then  the  Transfer-syntax-name  component  of  a  PDV-list 
value  shall  only  appear  in  the  CP  PPDU  and  CPC-type. 


8.7  Connectionless 

The  connectionless  Presentation  protocol  shall  be  implemented  as  specified  in  ISO  9576. 

The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  be  present  in  a  UD  PPDU  if  and  only  if 
more  than  one  transfer  syntax  name  was  proposed  for  the  Presentation  context  of  the  Presentation  data 
values.  The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  always  be  present  in  a  UDC-type. 
The  Transfer-syntax-name  component  of  a  PDV-list  value  shall  only  appear  in  the  UD  PPDU  and 
UDC-type. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 


9  Session 


9.1  Introduction 

This  clause  details  the  implementation  requirements  for  the  Session  layer  as  defined  in  the  Session 
Service  Definition,  ISO  8326  and  the  Session  Protocol  Definition,  ISO  8327. 


9.2  Services 

The  following  functional  units  are  within  the  scope  of  a  workshop-conformant  system: 


a) 

Kernel; 

b) 

Duplex; 

c) 

Expedited  Data; 

d) 

Resynchronize; 

e) 

Exceptions; 

f)  Activity  Management; 
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h)  Minor  Synchronize; 

i)  Major  Synchronize; 
j)  Typed  Data. 

9.3      Protocol  Agreements 

9.3.1  Concatenation 

When  a  category  0  SPDU  is  concatenated  with  a  category  2  SPDU,  the  category  0  SPDU  shall  not 
contain  User  Data. 

Extended  concatenation  is  not  required  and  can  be  refused  using  the  normal  negotiation  mechanisms  of 
the  Session  protocol. 

9.3.2  Segmenting 

Session  segmenting  is  not  required  and  can  be  refused  using  the  normal  negotiation  mechanisms  of  the 
Session  protocol.  All  conformant  implementations  shall  be  able  to  interwork  without  Session  segmenting. 

9.3.3  Reuse  of  Transport  Connection 

Reuse  of  a  Transport  connection  is  not  required  and  can  be  refused. 

9.3.4  Use  of  Transport  Expedited  Data 

The  Session  use  of  Transport  expedited  service  is  optional. 

NOTE  -  A  referencing  ABE  may  require  that  this  feature  shall  be  offered  by  an  initiating  implementation  if 
it  is  available,  and  that  it  shall  be  accepted  by  a  responding  implementation  if  it  is  available  and  was 
offered. 


9.3.5       Use  of  Session  Version  Number 

Session  Versions  1  and  2  are  recognized.  Each  relevant  SIG  chooses  the  version  or  versions  of  Session 
which  it  requires  for  a  particular  implementation  phase,  and  these  choices  are  documented  in  clause  12. 

Session  Version  2  specifies  the  use  of  unlimited  user  data  during  connection  establishment  as  dictated 
by  the  AD  2  to  ISO  8327  to  Incorporate  Unlimited  User  Data. 
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All  Session  Version  1  implementations  must  be  able  to  negotiate  Version  1  operation  when  responding 
to  a  CONNECT  (CN)  SPDU  proposing  both  Version  1  and  Version  2. 

In  addition,  all  Session  Version  1  implementations,  upon  receipt  of  a  CONNECT  (CN)  SPDU  proposing 
only  Version  2,  should  respond  with  a  REFUSE  (RF)  SPDU  containing  a  Reason  Code  indicating  that  the 
proposed  version  is  not  supported.  Until  pending  defect  reports  are  adopted,  implementations  may 
disconnect. 

If  Session  Versions  1  and  2  are  both  proposed  in  the  CONNECT  (CN)  SPDU,  then  the  maximum  length 
of  the  User  Data  parameter  value  in  the  CONNECT  (CN)  SPDU  shall  be  512  octets  and  a  PG!  field  of 
193  shall  be  associated  with  this  parameter.  This  implies  that  an  implementation  supporting  both  Session 
Versions  1  and  2  can  establish  a  connection  with  an  implementation  supporting  only  Version  1. 

If  only  Session  Version  2  is  proposed  in  the  CONNECT  (CN)  SPDU,  then  the  maximum  length  of  the 
Session  User  Data  parameter  value  of  the  S-CONNECT  service  request  shall  be  10,240  octets.  This 
restriction  implies  that  the  OVERFLOW  ACCEPT  (OA)  SPDU  and  CONNECT  DATA  OVERFLOW  (CDO) 
SPDU  are  not  used.  If  the  length  of  the  User  Data  parameter  value  is  no  greater  than  512  octets,  then  an 
associated  PGI  field  of  193  shall  be  used,  otherwise  a  PGI  field  of  194  shall  be  used. 

When  Session  Version  2  is  negotiated,  then  in  all  SPDUs  the  maximum  length  of  the  User  Data 
parameter  value  with  an  associated  PGI  field  of  193  shall  be  10,240  octets.  Workshop-conformant 
Session  Version  2  implementations  need  only  support  the  maximum  data  lengths  specified  in  the 
Specific  ASE  Requirements  section. 


9.3.6        Receipt  of  Invalid  SPDUs 

Upon  receipt  of  an  invalid  SPDU,  the  SPIV!  shall  take  any  action  in  A.4.3  of  the  Session  Protocol 
Definition  ISO/IS  8327  except  Action  d. 


9.3.7       Invalid  SPM  Intersections 

If  the  conditions  described  in  A.4.1.2  of  the  Session  Protocol  Definition  ISO/IS  8327  are  satisfied,  the 
SPM  shall  always  take  the  actions  described  by  A.4.1.2  a. 

This  implies  that  no  S-P-EXCEPTION-REPORT  indications  will  be  generated  nor  EXCEPTION  REPORT 
SPDUs  sent  due  to  invalid  intersections  of  the  Session  state  table  resulting  from  received  SPDUs. 


9.3.8  S-Selectors 

S-selectors  shall  be  a  maximum  of  16  octets. 
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The  connectionless  Session  protocol  shall  be  implemented  as  specified  in  ISO  9548. 

No  further  agreements  beyond  those  specified  elsewhere  in  this  part  have  been  made  regarding  this 
standard. 


10   UNIVERSAL  ASN.1  ENCODING  RULES 


10.1  TAGS 

The  maximum  value  of  an  ASN.1  basic  encoding  tag  that  need  be  handled  by  a  workshop-conformant 
implementation  shall  be  16,383.  This  is  the  maximum  unsigned  number  that  can  be  represented  in  14 
bits,  therefore,  the  maximum  encoding  of  a  tag  occupies  3  octets. 


10.2     Definite  Length 

The  maximum  value  of  an  ASN.1  length  octets  component  that  need  be  handled  by  an  workshop- 
conformant  implementation  shall  be  4,294,967,295.  This  is  the  maximum  unsigned  integer  that  can  be 
represented  in  32  bits,  therefore,  the  maximum  encoding  of  a  length  octets  component  will  occupy  5 
octets.  Also,  note  this  restriction  does  not  apply  to  indefinite  length  encoding. 


10.3  External 

It  is  assumed  that  "Presentation  layer  negotiation  of  encoding  rules"  is  always  in  effect,  and  therefore 
clause  32.5  of  the  Specification  of  ASN.1,  ISO  8824  never  applies. 

If  a  data  value  to  be  encapsulated  in  an  EXTERNAL  type  is  an  instance  of  a  single  ASN.1  type  encoded 
according  to  the  Basic  Encoding  Rules  for  ASN.1,  then  the  option  "single-ASN.I-type"  shall  be  chosen  as 
its  encoding. 

If  a  data  value  to  be  encapsulated  in  an  EXTERNAL  type  is  encoded  as  an  integral  number  of  octets, 
and  the  above  does  not  apply,  then  the  option  "octet-aligned"  shall  be  chosen  as  its  encoding. 


10.4  Integer 

Any  incidence  of  an  ASN.1  INTEGER  type  defined  in  an  abstract  syntax  describing  protocol  control 
information  must  be  encoded  so  that  the  length  of  its  contents  octets  is  no  more  than  four  octets,  unless 
an  explicit  Workshop  agreement  to  the  contrary  is  made  for  a  specific  INTEGER  type. 
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10.5    String  Types 

The  contents  octets  for  a  constructed  encoding  of  a  BIT  STRING,  OCTET  STRING,  or  character  string 
value  consists  of  the  complete  encoding  of  zero,  one,  or  more  data  values,  and  the  encoding  of  these 
data  values  must  be  primitive. 


10.6    Bit  String 

Unless  otherwise  specified  in  the  abstract  syntax  definition,  each  bit  named  in  a  BIT  STRING  type  used 
in  that  abstract  syntax  definition  shall  be  explicitly  encoded  in  the  associated  BIT  STRING  value,  even  if  it 
is  part  of  a  string  of  trailing  zero  bits. 

Extra  trailing  bits  beyond  the  exact  number  of  bits  which  correspond  to  the  complete  list  of  the  named 
bits  specified  shall  never  be  encoded.  This  rule  applies  to  all  BIT  STRING  types  unless  stated  otherwise 
in  the  standards. 


\  1 1    Character  Sets 

See  Part  21  of  Working  Implementation  Agreements. 


12  Conformance 

In  order  for  an  implementation  to  be  in  conformance  with  the  Implementors'  agreements,  the  rules  below 
shall  be  followed: 

a)  A  conformant  implementation  must  meet  all  of  the  requirements  of  this  specification.  All 
documents  referenced  in  the  Upper  Layers  part  shall  be  used  as  the  supporting  documents  for 
all  implementations  of  ACSE,  ROSE,  RTSE,  Presentation,  or  Session.  The  full  references  for 
these  documents  are  in  clause  2. 

b)  Workshop-conformant  implementations  shall  be  ISO  conformant.  PICS  may  contain 
limitations  on  length  or  value  aspects  of  a  protocol.  PICS  of  workshop-conformant  systems  shall 
not  contain  restrictions  more  severe  than  those  in  these  implementation  agreements. 

NOTE  -  An  implementation  may  abort  a  connection  if  the  constraints  specified  in  these  agreements  are 
violated. 
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13   Specific  ASE  Requirements 

The  following  list  for  each  ASE  the  corresponding  SIG's  requirements  of  and  restrictions  on  ACSE, 
ROSE,  RISE,  Presentation,  and  Session. 

All  listed  requirements  and  restrictions  shall  be  included  in  an  NIST-conformant  system  and  shall  be 
implemented  in  accordance  with  these  Implementor's  agreements. 

13.1  FTAMPhase2 

13.1.1  ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

Application  Contexts:  "ISO  FTAM"  {  iso(1)  standard(O)  8571  application-context  iso-ftam(l)  }  -  implies 
the  use  of  the  ACSE  and  the  FTAM  ASE. 

A  value  is  defined  for  the  AE  Title  only  to  satisfy  the  FTAM  requirement  for  exchanging  fields  of  this 
type.  This  value  does  not  identify  an  Application  Entity  and  carries  no  semantics. 

If  the  AE  title  is  used,  AE-title-form2  shall  be  supported.  Support  of  AE-title-form2  includes  support  of  AP- 
title-form2  and  AE-qualifier-form2. 

The  value  for  the  AP  title  is  {  1  3  9999  1  ftam-nil-ap-title  (7)  }  at  this  time.  Values  for  the  AE  qualifier  are 
outside  the  scope  of  these  agreements. 

The  use  of  AP  invocation  identifiers  and  AE  invocation  identifiers  by  FTAM  is  outside  the  scope  of  these 
agreements. 

13.1.2  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  At  least  3  Presentation  Contexts  must  be  supported. 
Abstract  Syntaxes: 

a)  Abstract  Syntaxes  for  conformant  Implementations 

1)  "ISO  8650-ACSE1"  {joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 ) 
apdus(O)  version1(1)  } 

2)  "FTAM-PCI"  {  iso(1)  standard(O)  8571  abstract-syntax(2)  ftam-pci(l)  } 

3)  "FTAM  unstructured  binary  abstract  syntax"  {  iso(1)  standard(O)  8571 
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abstract-syntax(2)  unstructured-binary(4)  } 
Editor's  Note  -  In  Definitions  below,  "NBS"  designation  will  be  preserved. 

b)  Abstract  Syntaxes  Depending  on  Implementation  Profile 

1)  "RAM-FADU"  {  iso(1)  standard(O)  abstract-syntax(2)  ftam-fadu(2)  } 

2)  "FTAM  unstructured  text  abstract  syntax"  {  iso(1)  standard  (0)  8571  abstract-syntax (2) 
unstructured-text(3)  } 

3)  "NBS  abstract  syntax  AS1"  {  iso  identified-organizatlon  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-as1(1)  } 

4)  "NBS  file  directory  entry  abstract  syntax"  {  iso  identified-organization  oiw(14) 
ftamsig(5)  abstract-syntax(2)  nbs-as2(2)  } 

c)  Associated  Transfer  Syntax: 

1)  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)} 

Editor's  Note  -  The  changes  above  involving  "0IW(14)"  were  not  explicitly  mentioned  at  the  March  1990 
Plenary,  but  were  implied  from  a  correspondingly  approved  FTAM  motion. 

13.1.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 

13.1.4  Session  Options 

Session  Functional  Units: 

a)  resynchronize  -  only  a  Resynchronize  Type  value  of  "abandon" 

b)  minor  synchronize 
NOTES 
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1  The  minor  synchronize  functional  unit  is  required  whenever  the  resynchronize  functional  unit  is  available. 

2  The  default  value  for  Minor  Sync  Point  Sync  type  item  shall  always  be  used,  i.e.,  explicit  confirmation  is 
required. 

13.1.5      ASN.1  Encoding  Requirements 

Some  INTEGER  types  of  the  FTAM  PCI  may  exceed  the  maximum  size  specified  in  the  UNIVERSAL 
ASN.1  ENCODING  Rules.  See  the  Range  of  values  for  INTEGER  type  Parameters  of  the  FTAM  part. 

13.2  MHS 

13.2.1  Phase  1  (1984  X.400)  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  half-duplex 

c)  exceptions 

d)  activity  management 

e)  minor  synchronize 
Version  Number:  1 

Maximum  size  of  User  Data  parameter  field:  512 
NOTES 

1  Restricted  use  is  made  by  the  RTS  of  the  Session  sen/ices  implied  by  the  functional  units  selected. 

,  .,  ,      Specifically,  1)  No  use  is  made  of  S-TOKEN-GIVE,  and  2)  S-PLEASE-TOKENS  only  asks  for  the  data  token. 

2  In  the  S-CONNECT  SPDU,  the  Initial  Serial  Number  should  not  be  present. 

3  The  format  of  the  Connection  Identifier  in  the  S-CONNECT  SPDU  is  described  in  Version  5  of  the  X.400- 
Series  Implementors'  Guide. 

13.2.2  Phase  2,  Protocol  PI  (1988  X.400) 
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13.2.2.2  RTSE  Requirements 

The  RTSE  requirements  are: 

a)  Monologue 

b)  TWA  -  optional 

c)  checkpointing: 

1)  minimum  checl<pointsize  =  1 

2)  minimum  windowsize  =  1 

d)  no  checkpointing 
For  the  Monologue  Association: 

a)  initiator  keeps  initial  turn 

b)  APDUs  are  transferred  from  initiator  to  responder  only 

c)  no  turn  passing 

d)  only  the  initiator  effects  the  orderly  release  of  an  association 
For  the  two  way  alternate  Association 

a)  the  initiator  may  keep  or  pass  the  initial  turn,  at  binding 

b)  APDUs  are  transferred  by  the  holder  of  the  turn 

c)  only  the  initiator  effects  the  orderly  release  of  an  association,  when  it  possesses  the  turn 

13.2.2.3  ACSE  Requirements 

As  per  Phase  2,  Protocol  P7. 
Application  Contexts: 

a)  "MTS-transfer-protocol-1984"  -  mandatory 

b)  "MTS-transfer-protocol"  -  mandatory 
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13.2.2.4  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  at  least  3  must  be  supported 

Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 )  apdus(O) 
version1(1)  } 

b)  "MTS-RTSE" 

c)  "MTSE" 

d)  Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2) 
asn1(1)  basic-encoding(l)  } 

13.2.2.5  Session  Requirements 

As  per  Phase  2,  Protocol  P7. 

13.2.3      Phase  2,  Protocol  P7  (1988  X.400) 

13.2.3.1  ROSE  Requirements 

Operation  and  association  classes  are  used  as  per  the  standard. 

13.2.3.2  RTSE  Requirements 

The  RTSE  requirements  are: 
,   a)  TWA 

b)  normal-mode 

c)  checkpointing 

d)  minimum  checkpointsize  =  1 

e)  minimum  windowsize  =  1 
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f)  no  checkpointing 
For  the  Monologue  Association: 

a)  initiator  keeps  initial  turn 

b)  APDUs  are  transferred  from  initiator  to  responder  only 

c)  no  turn  passing 

d)  only  the  initiator  effects  the  orderly  release  of  an  association 
For  two  way  alternate  Association: 

a)  the  initiator  may  keep  or  pass  the  initial  turn,  at  binding 

b)  APDUs  are  transferred  by  the  holder  of  the  turn 

c)  only  the  initiator  effects  the  orderly  release  of  an  association,  when  it  possesses  the  turn 

13.2.3.3  ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

The  use  of  AP-TITLE,  AE-QUALIFIER,  AP-INVOCATION-ID,  and  AE-INVOCATION-ID  is  not 
recommended;  however,  a  receiving  entity  must  be  capable  of  ignoring  them  (if  present)  without  refusing 
the  connection. 

Application  Contexts: 

a)  "MS-access"  -  mandatory;  normal  mode 

b)  "MS-reliable-access"  -  optional;  normal  mode 

13.2.3.4  Presentation  Requirements 

Presentation  Functional  Units:  kernel 
Presentation  Contexts:  at  least  5 
Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 )  apdus(O) 
version1(1)  } 

b)  MSBind/MSUnbind  (with  or  without  RISE) 
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c)  MSSE  (Message  Submission) 

d)  IVIASE  (Message  Administration) 

e)  MRSE  (Message  Retrieval) 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.2.3.5       Session  Requirements 

Session  Functional  Units: 

a)  l<ernel  .  , 

b)  half-duplex  (if  RISE  is  supported) 

c)  full-duplex  (if  RISE  is  not  supported) 

d)  exceptions 

e)  activity  management 

f)  minor  synchronize 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 


1  MHS  proposes  both  versions  1  and  2  for  pass  through  mode  (X.410  mode),  but  only  version  2  for 
normal  mode. 

2  Restricted  use  is  made  by  the  RTS  of  the  Session  services  implied  by  the  functional  units  selected. 
Specifically,  no  use  is  made  of  S-TOKEN-GIVE,  and  S-PLEASE-TOKENS  only  asks  for  the  data  token. 

3  in  the  S-CONNECT  SPDU,  the  Initial  Serial  Number  should  not  be  present. 

4  The  format  of  the  Connection  Identifier  in  the  S-CONNECT  SPDU  is  described  in  Version  5  of  the  X.400- 
Series  Implementors'  Guide. 


NOTES 


13.2.4 


Phase  2,  Protocol  P3  (1988  X.400) 
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13.2.4.1  ROSE  Requirements 

As  per  Phase  2,  P7. 

13.2.4.2  RTSE  Requirements 

As  per  Phase  2,  P7. 

13.2.4.3  ACSE  Requirements 

As  per  Phase  2,  P7. 
Application  Contexts: 

a)  "MTS-access"  -  mandatory 

b)  "MTS-reliable-access"  -  optional 

c)  "MTS-forced-access"  -  mandatory 

d)  "MTS-forced-reliable-access"  -  optional 

13.2.4.4  Presentation  Requirements 

As  per  Phase  2,  P7. 

13.2.4.5  Session  Requirements 

As  per  Phase  2,  P7. 

13.3    DS  Phase  1 

13.3.1      ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 
Application  Contexts: 

a)  "id-ac-directoryAccessAC"  {  joint-iso-ccitt(2)  ds(5)  3  1  } 

b)  "id-ac-directorySystemAC"  {  joint-iso-ccitt(2)  ds(5)  3  2} 


December  1991  (Stable) 
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13.3.2  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  At  least  2  Presentation  Contexts  must  be  supported. 
Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(l)  apdus(O) 
version!  (1)  } 

b)  "id-as-directoryAccessAS"  joint-iso-ccitt(2)  ds(5)  9  1  } 

c)  "id-as-directorySystemAS"  {  joint-iso-ccitt(2)  ds(5)  9  2} 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.3.3  Session  Requirements 

Session  Functional  Units: 
a)  kernel       . .  , 
.  b)  duplex 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 

13.4    Virtual  Terminal 
13.4.1      Phase  1a 

13.4.1.1       ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

Application  Contexts:  "ISO  VT"  {  iso(1)  standard(O)  9041  application-context(l)  }-  implies  the  use  of  the 
ACSE  and  the  VT  ASE 
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13.4.1.2  Presentation  Requirements 

Presentation  Functional  Units:  l<ernel 

Presentation  Contexts:  at  least  2  must  be  supported 

Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 )  apdus(O) 
version1(1)  } 

b)  "VT  Basic"  {  iso(1)  standard(O)  9041  abstract-syntax(2)  } 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.4.1.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 

c)  expedited  data 

d)  major  synchronize 

e)  resynchronize  -  only  a  Resynchronize  Type  value  of  "restart" 

f)  typed  data 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 
Session  Options:  expedited  data 

13.4.2      Phase  1b 

13.4.2.1       ACSE  Requirements 

ACSE  Functional  Requirements:  Kernel 

Application  Contexts:  "ISO  VT"  {  iso(1)  standard(O)  9041  application-context (1)  }  -  implies  the  use  of  the 
ACSE  and  the  VT  ASE 
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13.4.2.2  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  at  least  2  must  be  supported 

Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 )  apdus(O) 
version1(1)  } 

b)  "VT  Basic"  {  iso(1)  standard  (0)  9041  abstract-syntax(2)  } 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 

13.4.2.3  Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 

c)  half-duplex 

d)  expedited  data 

e)  major  synchronize 

f)  resynchronize  -  only  a  Resynchronize  Type  value  of  "restart" 

g)  typed  data 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 
Session  Options:  expedited  data 
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13.5.1  ACSE  Requirements 

ACSE  Functional  Units:  Kernel 

Application  Context:  "ISO  MMS"  {  iso(1)  standard(O)  9506  part(2)  mms-application-context-version1(3)}  - 
implies  use  of  ACSE  and  MMS  ASE 

13.5.2  Presentation  Requirements 

Presentation  Functional  Units:  Kernel 

At  least  2  Presentation  Contexts  must  be  supported. 

Abstract  Syntaxes: 

a)  "mms-abstract-syntax-major-version1"  {  iso(1)  standard(O)  9506  part(2)  mms-abstract-syntax- 
major-version1  (1)} 

b)  "ISO  8650-ACSE1"  {joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 )  apdus(O) 
version1(1)} 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {joint-iso-ccitt(2)  asn1(1)  basic- 
encoding(1)} 

13.5.3  Session  Requirements 

Session  Functional  Units: 

a)  Kernel 

b)  Duplex 
Version  Number:  2 

Maximum  size  of  User  Data  parameter  field:  10,240 
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13.6  Transaction  Processing 

See  Working  Implementation  Agreements  Document. 

13.7  Network  Management 
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13.7.1  ROSE  Requirements 

The  Rose  requirements  are  as  specified  in  ISO  9596  section  5.2:  Underlying  Services,  and  section  6.2 
Remote  Operations. 

Operations  Classes:  1 ,  2,  and  5 

Association  Classes:  3 

13.7.2  ACSE  Requirements 

ACSE  Functional  Units:  kernel 
Application  Contexts:  as  defined  by  [SMO] 

AE-Title:  The  association  responder  shall  support  both  forms  of  the  AE-Title.  The  association  requestor 
may  use  either  form  of  the  AE-Title. 

13.7.3  Presentation  Requirements 

Presentation  Functional  Units:  kernel 

Presentation  Contexts:  At  least  2  must  be  supported. 

Abstract  Syntaxes: 

a)  "ISO  8650-ACSE1"  {  joint-iso-ccitt(2)  association-control (2)  abstract-syntax(1 )  apdus(O) 
,  ;         version1(1)  } 

b)  "CMIP-PCI"  {joint-iso-ccitt(2)  ms(9)  cmip(1)  cmip-pci(1)  abstractSyntax(4)} 

Associated  Transfer  Syntax:  "Basic  Encoding  of  a  single  ASN.1  type"  {  joint-iso-ccitt(2)  asn1(1) 
basic-encoding(l)  } 
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13.7.4      Session  Requirements 

Session  Functional  Units: 

a)  kernel 

b)  duplex 
Version  Number:  2 

Maximunfi  size  of  User  Data  parameter  field:  10,240, 
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Annex  A  (normative) 
Object  Identifier  Register 

Editor's  Note  -  Annexes  A  and  B  have  been  switched  to  place  the  informative  annex  after  the  normative 
annex. 


A.1      Register  Index 

Each  entry  in  the  index  contains  an  object  Identifier  value  and  a  reference  to  the  clause  describing  the 
object  Identifier's  use: 

a)  {  lso(1)  identlfied-organization(3)  olw{14)  ulsig(8)  appllcation-context(l)  nli(1)  }  is  defined  In 
14.2; 

b)  {  lso(1)  identified-organization(3)  oiw(14)  ulsig(8)  abstract-syntax(2)  octet-string(l)  }  is 
defined  In  14.2. 


A.2      Object  Identifier  Descriptions 

{  iso(1)  ldentified-organizatlon(3)  oiw(14)  ulslg(8)  appllcation-context(l)  nil(1)  } 

This  application  context  may  be  used  by  applications  having  a  prior  agreement  regarding  the  application 
context. 

NOTE  -  This  value  is  intended  to  be  used  by  private  applications  that  have  an  a  priori  agreement 
concerning  the  set  of  ASEs,  related  options,  and  any  other  information  necessary  for  the  interworking  of 
AEs  on  an  application  association.  This  value  does  not  identify  any  specific  application  context  and  cannot 
be  used  to  identify  the  intended  communications  environment  for  the  application  association.  Therefore,  it 
is  strongly  recommended  that  private  applications  define  and  register  an  object  identifier  for  their 
application  context. 

{  iso(1)  ldentifled-organlzation(3)  olw(14)  ulslg(8)  abstract-syntax(2)  octet-string(l)  } 


NIST-OIW-ULSI G- AS -octet 

-string 

DEFINITIONS 

::=  BEGIN 

Single-octet-string 

: :=     OCTET  STRING 

END 

This  abstract  syntax  may  be  used  by  applications  having  a  prior  agreement  regarding  the  content  of  the 
octet  string. 
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Annex  B  (informative) 
Recommended  Practices 

Editor's  Note  -  Annexes  A  and  B  have  been  switched  to  place  the  informative  annex  after  the  normative 
annex. 

The  optional  "Reflect  Parameter  Values"  parameter  In  the  Provider  ABORT  SPDU  shall  be  encoded  so  as 
to  represent  the  Session  connection  state,  the  Incoming  event  and  the  first  invalid  SPDU  field  exactly  at 
the  moment  a  protocol  error  was  detected. 

The  first  octet  encodes  the  Session  state  as  a  number  relative  to  0  as  detailed  In  table  1. 
The  second  octet  encodes  the  incoming  event  as  a  number  relative  to  0  as  detailed  in  table  2. 
The  third  octet  contains  the  SI,  PGI,  or  PI  Code  of  any  SI  field,  PGI  unit  or  PI  unit  in  error. 
NOTE  -  The  remaining  6  octets  are  undefined  herein. 
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Table  1  -  Session  States 


state 

Rel 

Description 

1 

0 

Idle 

no 

transport  connection 

IB 

1 

Wait 

for 

T-connect  confirm 

IC 

2 

transport  connected 

2A 

3 

Wai  t 

for 

the  ACCEPT  SPDU 

3 

4 

Wait 

for 

the  DISCONNECT  SPDU 

8 

5 

Wait 

for 

the  S-CONNECT  response 

9 

6 

Wait 

for 

the  S-RELEASE  response 

16 

7 

Wait 

for 

the  T-DISCONNECT  indication 

713 

8 

Data 

Transfer  state 

lA 

9 

Wait 

for 

the  ABORT  ACCEPT  SPDU 

4A 

10 

Wai  t 

for 

the  MAJOR  SYNC  ACK  SPDU  or  PREPARE  SPDU 

4B 

11 

Wait 

for 

the  ACTIVITY  END  ACK  SPDU  or  PREPARE  SPDU 

5A 

12 

Wait 

for 

the  RESYNCHRONIZE  ACK  SPDU  or  PREPARE  SPDU 

53 

13 

Wait 

for 

the  ACTIVITY  INTERRUPT  SPDU  or  PREPARE  SPDU 

5C 

14 

Wait 

for 

the  ACTIVITY  DISCARD  ACK  SPDU  or  PREPARE  SPDU 

6 

15 

Wai  t 

for 

the  RESYNCHRONIZE  SPDU  or  PREPARE  SPDU 

lOA 

16 

Wait 

for 

the  S-SYNC-MAJOR  response 

lOB 

17 

Wait 

for 

the  S-ACTIVITY-END  response 

llA 

18 

Wait 

for 

the  S-RESYNCHRONIZE  response 

IIB 

19 

Wait 

for 

the  S-ACTIVITY-INTERRUPT  response 

lie 

20 

Wait 

for 

the  S-ACTIVITY-DISCARD  response 

15A 

21 

After 

PREPARE,  wait  for  the  MAJOR  SYNC  ACK  SPDU 

or  the  ACTIVITY  END  ACK 

15B 

22 

After 

PREPARE,  wait  for  the  RESYNCHRONIZE  SPDU 

or  the  ACTIVITY  DISCARD  SPDU 

15C 

23 

After 

PREPARE,  wait  for  the  RESYNCHRONIZE  ACK  SPDU, 

or  the  ACTIVITY  INTERRUPT  ACK  SPDU 

or  the  ACTIVITY  DISCARD  ACK  SPDU 

18 

24 

Wait 

for 

GIVE  TOKENS  ACK  SPDU 

19 

25 

Wait 

for 

a  recovery  request  or  SPDU 

20 

26 

Wait 

for 

a  recovery  SPDU  or  request 

21 

27 

Wait 

for 

the  CAPABILITY  DATA  ACK  SPDU 

22 

28 

Wait 

for 

the  S-CAP ABILITY-DATA  response 

ID 

29 

Wait 

for 

the  CONNECT  DATA  OVERFLOW  SPDU 

2B 

30 

Wait 

for 

the  OVERFLOW  ACCEPT  SPDU 

15D 

31 

After 

PREPARE,  wait  for  the  ABORT  SPDU 
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Table  2  -  Incoming  Events 


Event 

Rel 

Description 

SCONreq 

0 

S-CONNECT  request 

SCONrsp 

1 

S-CONNECT  accept  response 

SCONrsp 

2 

S-CONNECT  reject  response 

SDTreq 

3 

S-DATA  request 

SRELreq 

4 

S-RELEASE  request 

SRELrsp 

5 

S-RELEASE  accept  response 

SUABreq 

6 

S-U- ABORT  request 

TCONcnf 

7 

T-CONNECT  confirmation 

TCONind 

8 

T-CONNECT  indication 

TDISind 

9 

T-DISCONNECT  indication 

TIM 

10 

Time  out 

AA 

11 

ABORT  ACCEPT 

AB-nr 

12 

ABORT  -  no  reuse 

AC 

13 

ACCEPT 

CN 

14 

CONNECT 

DN 

15 

DISCONNECT 

DT 

16 

DATA  TRANSFER 

FN-nr 

17 

FINISH  -  no  reuse 

RF-nr 

18 

REFUSE  -  no  reuse 

SACTDreq 

19 

S~ACTIVITY-DISCARD  request 

SACTDrsp 

20 

S-ACTIVITY-DISCARD  response 

SACTEreq 

21 

S-ACTIVITY-END  request 

SACTErsp 

22 

S-ACTIVITY-END  response 

SACTIreq 

23 

S-ACTIVITY-INTERRUPT  request 

SACTIrsp 

24 

S-ACTIVITY-INTERRUPT  response 

SACTRreq 

25 

S-ACTIVITY-RESUME  request 

SACTSreq 

26 

S-ACTIVITY-START  request 

SCDreq 

27 

S-CAPABILITY-DATA  request 

SCDrsp 

28 

S-CAPABILITY-DATA  response 

SCGreq 

29 

S-CONTROL-GIVE  request 

SEXreq 

30 

S-EXPED I TED-DATA  request 

SGTreq 

31 

S-TOKEN-GIVE  request 

SPTreq 

32 

S-TOKEN-PLEASE  request 

SRELrsp 

33 

S-RELEASE  response  reject 

oKo  iiMreq  (a) 

■J  A 
■31 

o— Kilo xiNJt^nKuiNi requests  aoanaon 

SRSYNreq(r ) 

35 

S-RESYNCHRONIZE  request  restart 

SRSYNreq(s) 

36 

S-RESYNCHRONIZE  request  set 

SRSYNrsp 

37 

S-RESYNCHRONIZE  response 

SSYNMreq 

38 

S-SYNC -MAJOR  request 

SSYNMrsp 

39 

S-SYNC-MAJOR  response 

SSYNmreq 

40 

S-SYNC-MINOR  request 

SSYNmrsp 

41 

S-SYNC-MINOR  response 

STDreq 

42 

S-TYPED-DATA  request 

SUERreq 

43 

S-U-EXCEPT ION-REPORT  request 
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Table  2  -  Incoming  Events  (continued) 


Event 

Rel 

AB-r 

44 

AD 

45 

ACTIVITY  DISCARD  SPDU 

ADA 

46 

ACTIVITY  DISCARD  ACK  SPDU 

AE 

47 

ACTIVITY  END  SPDU 

AEA 

48 

ACTIVITY  END  ACK  SPDU 

AI 

49 

ACTIVITY  INTERRUPT  SPDU 

AIA 

50 

ACTIVITY  INTERRUPT  ACK  SPDU 

AR 

51 

ACTIVITY  RESUME  SPDU 

AS 

52 

ACTIVITY  START  SPDU 

CD 

53 

CAPABILITY  DATA  SPDU 

CDA 

54 

CAPABILITY  DATA  ACK  SPDU 

N^AiX  C  \  1  /  X  XJ  XXX      X/X^  X  X*     <*Vi^  A\           X  1^  V 

ED 

55 

EXCEPTION  DATA  SPDU 

XJ^^^^XJX    X  X                    A^X*  X  *k             X  mJ\J 

ER 

56 

EXCEPTION  REPORT  SPDU 

JkV^ XJ X   X  X  ^^L^           '  *      ^^X\  X           X  w 

EX 

57 

EXPEDITED  DATA  SPDU 

XjaTWX  XjX^  X  X  XjX/      X//4  X  a1          X  X/ V 

FN-r 

58 

FINIJ3H  —   rpusp  SPDU 

VJ  X  V  J-J     X  Vii</  i\  XJ  IN  O     l9x  X/  ^ 

GTA 

60 

RTVE  TOKENS  ACK  SPDU 

GTC 

61 

GIVE  TOKENS  CONFIRM  SPDU 

MAA 

62 

MA.TOR  SYNC  ACK  SPDU 

MAP 

63 

MAJOR  SYNC  POINT  SPDU 

MIA 

64 

MAJOR  SYNC  ACK  SPDU 

1                  X\           X  IV                    1\      U  X  1^  w 

MIP 

65 

MINOR  SYNC  POINT  SPDU 

NF 

66 

NOT  FINISHED  SPDU 

1^^^  X        X    X&^X^^UXjA^             X  ^/ 

PR-MAA 

67 

PREPARE   (MAJOR  SYNC  ACK)  SPDU 

PR-RA 

68 

PREPARE   (RESYNCHRONIZE  ACK)  SPDU 

PR-RS 

69 

PREPARE   (RESYNCHRONIZE)  SPDU 

PT 

70 

PLEASE  TOKENS  SPDU  with  Token  Item  Paramet  r 

RA 

71 

RESYNCHRONIZE  ACK  SPDU 

RF-r 

72 

REFUSE  -  reuse  SPDU 

RS-a 

73 

RESYNCHRONIZE  -  abandon  SPDU 

RS-r 

74 

RESYNCHRONIZE  -  restart  SPDU 

RS-s 

75 

RESYNCHRONIZE  -  set  SPDU 

TD 

76 

TYPED  DATA  SPDU 

CDO 

77 

CONNECT  DATA  OVERFLOW  SPDU 

0A7 

80 

VERFLOW  ACCEPT  SPDU 

PR-AB 

79 

PREPARE   (ABORT)  SPDU 

iv 
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PART  6  -  REGISTRATION  AUTHORITY  PROCEDURES  FOR  THE  OSI  IMPLEMENTORS 
WORKSHOP  (OIW)  December  1991  (Stable) 


Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Registration  Special  Interest  Group 
(RSIG)  of  the  Open  Systems  Interconnection  Implementors'  Workshop  (OIW). 

This  part  replaces  the  previously  existing  chapter  on  this  subject.  There  is  no  significant  technical  change 
from  this  text  as  previously  given. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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Part  6  -  Registration  Authority  Procedures  for  the  OSI  Implementors 
Workshop  (OIW) 

NOTE  -  Previous  material  in  this  section  has  been  deleted  and  is  no  longer  applicable. 

This  chapter  establishes  the  policies  and  procedures  for  the  registration  of  technical  objects  defined  by  the 
OSI  Implementors  Workshop.  Procedures  for  registering  operational  and  administrative  objects,  such  as  the 
MHS  ADMD  and  PRMD  names  and  addresses,  are  outside  the  scope  of  this  chapter. 


0  Introduction 

In  order  to  communicate,  it  is  necessary  to  identify  the  objects  involved  in  communication.  These  objects 
have  names  and  addresses.  A  name  identifies  an  object  within  the  domain  of  a  registration  authority.  An 
address  is  a  name  that  is  used  to  specify  the  physical  or  logical  location  of  an  object. 

OSI  names  and  addresses  consist  of  attributes  which  are  hierarchical  in  nature  and  which  combine  to 
identify  or  locate  an  OSI  object  unambiguously.  Since  the  relationship  between  the  components  of  a  name 
or  address  is  hierarchical,  it  follows  that  the  registration  authority  for  names  and  addresses  should  also  be 
hierarchical.  A  governing  organization  does  not  always  have  sufficient  knowledge  of  organizations  lower 
in  the  hierarchy  to  assign  values  within  those  organizations.  Thus,  an  approach  frequently  taken  is  to 
delegate  registration  authority  to  the  lower  organizations. 

Hierarchy  implies  an  inverted  tree-like  structure  where  the  number  of  objects  increases  from  the  root  of  the 
tree  to  the  leaves  of  the  tree.  At  the  root  of  the  tree,  there  is  one  designator  that  has  the  greatest  scope 
of  authority  (largest  domain).  This  designator  assigns  identifier  values  to  objects  under  its  authority.  Each 
of  these  objects  has  a  smaller  scope  of  authority  than  the  objects  immediately  above  and  may  create  zero, 
one,  or  many  subauthorities  at  the  next-lower  level.  The  number  of  levels  in  such  a  tree-like  structure  is 
arbitrary. 


1  Scope 

This  part  defines  registration  procedures  for  OSI  Implementors  Workshop  (OIW)  information  objects  and 
identifies  additional  registration  requirements.  These  procedures  shall  be  used  by  the  Special  Interest 
Groups  (SIGs)  of  the  Workshop  to  register  information  objects  used  in  OSI  communications  according  to 
the  OIW  Agreements  Document. 

In  this  part,  the  OIW  and  the  SIGs  themselves  are  assigned  arcs  in  the  object  identifier  tree.  These  arcs  are 
for  OlW-specified  objects.  The  SIGs  should  note  that,  as  national  and  international  registration  authorities 
are  established,  objects  of  interest  beyond  the  Workshop  are  more  appropriately  registered  by  a  higher  level 
in  the  hierarchy.  This  will  allow  more  widespread  acceptance  of  the  registered  objects. 

This  part  is  structured  as  follows:  6.2  describes  the  information  objects  that  need  to  be  registered,  and  6.3 
describes  a  registration  procedures  for  OIW  object  identifiers.  Annex  A  lists  the  object  identifier  component 
values  assigned  to  the  OIW  and  the  SIGs.  Annex  B  discusses  object  identifiers  used  in  the  1987  and  1988 
Stable  Implementation  Agreements.  The  appendices  are  integral  parts  of  this  specification. 
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2     Normative  References 


3     Registered  Information  Objects 

If  networks  are  to  interoperate  as  envisioned  in  the  OSI  model,  there  nriust  be  a  universal  open  and  agreed 
upon  naming  schema.  There  are  many  information  objects  that  fall  under  this  requirement. 

Some  of  the  following  objects  are  registered  in  the  standards,  some  are  registered  by  OIW  and  others  by 
other  registration  authorities.  An  example  list  of  objects  to  be  registered  is: 

a)  Application-process-titles; 

b)  Application-entity-titles; 

c)  Abstract  syntaxes; 

d)  Transfer  syntaxes; 

e)  Application-contexts; 

f)  MHS; 

1)  ADMD  names; 

2)  PRMD  names; 

3)  Organization  names; 

4)  Encoded  information  types; 

5)  Extended  body  part  types; 

6)  Extensions; 

7)  etc.; 

g)  Object  Identifier  values; 

h)  ASN.1  modules; 

i)  Directory; 

1)  Relative  distinguished  names; 

2)  Attribute  types; 

3)  Attribute  syntaxes; 
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4)  Object  classes; 

5)  Encryption  algorithms; 

6)  etc.; 

j)  VT; 

1)  Profiles; 

2)  Reference  information  objects; 

3)  etc.; 

k)  Networl<  management  objects; 
I)  Network  layer  addresses; 
m)  System  titles; 
n)  FTAM; 

1 )  Document  types; 

2)  Constraint  sets; 

3)  etc.; 

o)  etc. 

The  OIW  Registration  Authority  shall  only  administer  information  objects  created  by  the  OIW  Agreements 
Document  that  are  identified  by  the  ASN.1  type  OBJECT  IDENTIFIER.  Figure  1  illustrates  the  structure  of 
the  object  identifier  component  value  for  OIW. 


(  iso  identif ied-organization    oiw  (14)  ) 
iso(l) 

identif ied-organization( 3 ) 

oiw( 14 ) 


Figure  1  -  Structure  of  Object  Identifier  for  OIW. 

As  an  example  figure  2  shows  the  object  identifier  component  value  for  an  example  object. 
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(  iso    identif ied~organization  oiw(14)  rasig(13) 

example ( 0 ) } 

iso(l) 

identif ied-organization( 3 ) 

rasig(13) 

example ( 10 ) 

Figure  2  -  Structure  of  an  Object  Identifier  for  an  Example  Object  for  the  Registration  Authority  BIG 

of  OIW. 

The  ISO  6523  Registration  Authority  has  assigned  an  International  Code  Designator  (ICD)  value  of  14  to 
OIW,  and  OIW  has  assigned  a  unique  object  identifier  component  value  to  each  SIG.  The  assigned  object 
ID  values  for  the  OIW  and  for  each  SIG  are  in  Annex  A.  The  assignment  of  values  below  each  SIG  in  the 
object  identifier  tree  is  the  responsibility  of  that  SIG. 


4     Registration  Procedures  for  Object  Identifiers 

This  clause  specifies  the  responsibilities  of  each  SIG  and  the  procedures  to  be  followed  for  the  registration 
of  information  objects,  and  submission  to  the  OIW  Plenary. 

When  an  OIW  SIG  defines  an  information  object  the  SIG  shall  register  the  object  identifier.  The  registered 
value  shall  be  incorporated  into  the  appropriate  OIW  Agreements  Document  as  a  result  of  a  positive  ballot 
response  of  the  OIW  Plenary. 


4.1      SIG  Registration  Authorization 

An  OIW  SIG  is  authorized  by  its  charter  and  the  scope  of  its  work  to  submit  a  registration  request  to  the 
OIW  Plenary. 


4.2      SIG  Registration  Authority  Function  and  Duties 

The  SIG  Chair  is  responsible  for  the  assignment,  recording  and  maintenance  of  the  SIG's  registered  objects. 
The  SIG  Chair  may  appoint  a  specific  person  to  carry  out  the  SIG  duties  and  responsibilities. 
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4.3      Requirements  for  Information  Object  Registration 


4.3.1       Assignment  of  Object  Identifier  Component  Values 

Each  SIG  shall  register  an  object  identifier  component  value  for  each  object's  technical  definition.  The 
NameAndNumberForm  of  the  ObjIdComponent  specified  in  ISO  8824/CCiTT  X.208  is  used  exclusively.  This 
form  comprises  an  ASN.1  identifier  and,  significantly,  a  NumberForm. 

It  is  suggested  that  the  SIG  assign  a  monotonically  increasing  integer  to  the  NumberForm  at  any  given  level. 
To  the  significant  root  the  SIG  shall  add  a  assigned  object  identifier  component  value  that  shall  be  unique. 
An  example  of  an  object  identifier  created  by  the  RASIG  is  shown  as  follows: 

{iso(1)identified-organization(3)  oiw(14)  rasig(13)  example(O)} 

Here  rasig  is  the  SIG  identifier  and  13  is  the  NumberForm  assigned  by  the  OIW  Registration  Authority  (see 
Annex  A);  example  is  the  identifier  and  0  is  the  NumberForm  assigned  by  the  RASIG. 


4.3.2       Proposal  of  Object  and  Identifier  to  Plenary 

Registration  of  an  object  identifier  and  its  definition  is  proposed  by  inclusion  of  the  object  identifier  and  its 
definition  in  the  OIW  "Working  Implementation  Agreements"  document. 


4.3.3       Completion  of  Registration  Procedure 

Registration  of  an  object  identifier  and  its  definition  is  completed  upon  Plenary  vote  to  move  "Working 
Implementation  Agreements"  text  which  contains  the  object  identifier  and  its  definition  to  the  "Stable 
Implementation  Agreements"  document. 


4.3.4       Changes  and  Revisions  to  the  information  Object  Registration 

Neither  the  technical  definition  nor  the  object  identifier  shall  be  changed  or  modified  after  registration  i.e., 
after  the  definitions  and  their  identifiers  have  been  voted  into  the  "Stable  Implementation  Agreements" 
document. 
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4.4      Register  Index 

Each  SIG  shall  maintain  an  index  of  object  identifiers  that  point  to  the  technical  definitions  of  the  respective 
objects  in  the  OIW  Agreements  Document.  The  index  shall  appear  in  the  appropriate  part  annexes  of  the 
OIW  Agreements  Document. 


Table  1  -  Index  Entry  Example 


Object  Identifier 

Reference 

iso  identified-organization 

4.3.1 

oiw(14)  rasig(13)  example(O) 
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Annex  A  (normative) 

Assignments  to  Workshop  Organizations 


Table  2  -  Identifier  Assignments 


Identifier 

Value 

Assigned  To 

Assigned  By 

oiw 

14 

OIW 

ISO  6523  RA 

llsig 

1 

SIG 

OIW 

nmsig 

2 

SIG 

OIW 

secsio 

3 

SIG 

OIW 

tpsig 

4 

SIG 

OIW 

ftamsig 

5 

SIG 

OIW 

mhsig 

6 

SIG 

OIW 

dssig 

7 

SIG 

OIW 

ulsig 

8 

SIG 

OIW 

rdasig 

9 

SIG 

OIW 

mmssig 

10 

SIG 

OIW 

odasig 

11 

SIG 

OIW 

vtsig 

12 

SIG 

OIW 

rasig 

13 

SIG 

OIW 

PART  6  -  REGISTRATION  AUTHORITY  PROCEDURES  FOR  THE  OSI  IMPLEMENTORS 
WORKSHOP  (OWN)  December  1991  (Stable) 


Annex  B  (normative) 


Status  of  1987  and  1988  Ad-hoc  Object  Identifiers 

In  the  1987  and  1988  versions  of  the  Stable  Implementation  Agreements,  a  number  of  OlW-specified 
information  objects  are  assigned  object  identifiers. 

OSI  requires  names  and  addresses,  e.g.,  object  identifiers,  be  globally  unambiguous.  This  chapter  specifies 
object  identifier  component  values  which  are  globally  unambiguous.  Other  chapters  in  this  document 
specify  the  correct  object  identifiers  to  be  used  when  referencing  OlW-specified  information  objects. 

The  use  of  the  1987  and  1988  OlW-specified  object  identifiers  is  deprecated.  Newly  defined  objects  shall 
use  the  new  OIW  Identifier. 
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Annex  C  (informative) 

Guidelines  for  Registering  Changes  to  Technical  Objects 

Part  6  of  the  OIW  Agreements  document  describes  the  process  for  registering  technical  information  objects 
that  are  defined  in  the  development  of  OIW  implementation  agreements.  However,  the  process  does  not 
describe  a  criteria  for  determining  when  a  change  to  an  object  definition  is  of  sufficient  magnitude  to  require 
registration  of  a  new  object  with  a  new  01 D.  Such  criteria  would  be  useful  when  changes  are  proposed  to 
technical  object  definitions  that  have  already  been  registered. 

The  registration  procedures  for  technical  information  objects  in  OIW  Implementation  Agreements  assumes 
that  each  object  is  uniquely  different  in  particular  ways  from  all  other  registered  technical  information  objects, 
and  requires  that  there  is  exactly  one  definition  for  each  registered  object  identifier  (01 D).  Therefore,  when 
an  object  definition  is  to  be  changed,  it  must  receive  a  new  OID  if  the  change  is  "sufficiently  significant,"  in 
order  to  signal  to  all  concerned  parties  that  something  significant  has  been  changed. 


The  purpose  of  this  tutorial  section  is  to  provide  a  guide  for  the  evaluation  of  proposed  changes  to  the 
definition  of  a  technical  object.  Many  of  the  changes  will  fall  in  a  gray  area  between  an  obvious  "editorial 
change"  with  no  change  to  the  operational  characteristics  of  the  registration  and  "significant  change"  that 
will  require  the  requested  change  to  be  registered  as  a  new  technical  object  with  a  new  Object  Identifier 
(OID). 

These  guidelines  are  presented  to  assist  in  providing  a  consistent  approach  for  reviewing  requests  and 
making  changes  to  any  registered  technical  object. 

C.1      Evaluating  Registered  Technical  Objects 

Technical  objects  in  the  OIW  registers  include  a  functional  definition  describing  the  object,  its  states  and  the 
actions  that  can  change  the  object's  states.  The  definition  and  actions  of  the  object  are  usually  presented 
as  descriptive  text,  while  the  state  may  be  defined  by  a  data  structure  and  a  set  of  values  such  as  constants 
or  ranges,  having  a  particular  syntax.  It  should  be  recognized  as  stated  above  that  modifying  or  deleting 
one  or  more  parts  of  the  definition  may  not  be  of  sufficient  importance  to  require  the  registration  of  the 
registered  technical  object  under  another  identifier  (OID). 

For  example,  we  should  note  that  sometimes  a  change  may  be  desired  to  specifically  reduce  confusion  that 
stems  from  different  interpretations  of  a  given  definition.  In  this  case,  the  change  might  require  some 
implementations  to  be  modified  to  conform  to  a  chosen  interpretation,  but  who  Is  to  say  that  the  definition 
was  changed,  versus  saying  that  the  original  intent  was  finally  made  clear?  It  is  a  matter  of  judgement  by 
the  responsible  OIW  SIG  to  decide  whether  a  new  OID  should  be  assigned  in  this  case,  or  not. 

When  a  change  is  sufficiently  significant  to  require  a  new  OID,  then  the  old  object  must  remain  unchanged 
with  its  old  OID. 
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Review  criteria  must  consider  the  relative  importance  of  tlie  parts  of  the  technical  object  definition  that  are 
affected  by  a  change  before  determining  whether  to  approve  the  proposed  change.  Deciding  not  to  accept 
a  proposed  change  may  result  in  a  need  to  create  a  new  technical  object  very  similar  to  the  one  being 
reviewed. 


C.2     A  Registration  Review  Criteria 

The  significant  components  of  the  technical  definition,  to  which  a  criteria  can  be  applied  include  the  text 
description  of  the  technical  object,  the  definitions  of  the  state  values,  and  the  definitions  of  the  data 
structures.  The  criteria  is  not  intended  to  be  regulatory  in  nature,  but  to  provide  some  direction  in  reviewing 
each  of  the  three  components  when  evaluating  change  requests  for  registered  technical  objects. 


C.2.1       The  Technical  Object  Description 

Does  the  proposed  definition  change  or  require  a  uniquely  different  set  of  functions  or  state  conditions,  or 
does  the  proposed  change  alter  the  relationship  between  functions  of  the  registered  object? 

If  the  proposed  definition  change  adds  another  function  or  creates  another  state,  or  modifies  the  relationship 
between  functions  or  state  conditions  of  the  object,  or  deletes  a  defined  function  or  state  condition  then  the 
proposed  change  should  be  registered  as  a  new  technical  object  with  a  new  DID,  provided  that  the 
proposed  change  would  have  a  significant  impact  upon  the  implementation  or  operation  of  the  technical 
object  when  changed. 

Editorial  changes  can  be  made  to  correct  grammatical  errors  or  to  improve  clarity,  without  changing  the 
definition.  For  changes  that  require  additions  or  deletions  of  text  to  the  definition,  an  evaluation  must  be 
made  to  determine  if  the  changes  when  applied  are  optional  or  will  apply  only  to  a  local  implementation, 
or  are  extensive  enough  to  require  a  new  implementation. 

Deciding  what  change  means  with  respect  to  the  functional  definition  is  a  subjective  view  and  will  require 
that  each  SIG  establish  some  guidelines  for  its  particular  object  types.  Consistency  of  application  of  a 
registration  policy  within  each  SIG  would  be  most  helpful  to  the  process. 

One  approach  is  to  rule  that  any  change,  other  than  a  spelling  or  grammar  change  requires  a  new  technical 
object  registration.  However,  the  consequence  of  such  a  rule  would  be  a  large  number  of  registered 
technical  objects  with  very  similar  definitions  that  can  create  considerable  confusion  for  implementors.  The 
opposite  position  is  to  treat  any  change  to  the  functional  description  as  an  editorial  change,  and  only 
changes  to  the  other  criteria  like  the  state  values  or  data  structures  are  evaluated  to  make  a  decision  about 
registration  of  the  changed  object  as  a  new  technical  object. 

Between  the  two  is  a  more  acceptable  view  that  provides  for  the  evaluation  of  the  proposed  change  to 
decide  whether  the  change  is  editorial  only,  NOT  affecting  implementation;  or  if  it  is  a  change  in  functionality 
that  MAY  affect  implementation.  If  it  does  NOT  affect  implementation,  then  it  is  an  editorial  change.  If  it  MAY 
affect  the  implementation,  then  the  change  requested  should  be  evaluated  for  registration  as  a  new  technical 
information  object  with  a  new  OID. 

An  Example: 
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Change#1.  A  given  registered  object  includes  a  range  of  values  for  a  particular  attribute  called  TIMEOUT. 
It  includes  the  following  two  facts: 

a)  a  definition  of  the  TIMEOUT  attribute; 

b)  the  range  of  values  for  the  TIMEOUT  attribute. 

If  the  range  of  the  TIMEOUT  attribute  is  changed  from  10..  100  to  be  10..  1000,  it  is  possible  that  the  change 
is  not  significant  enough  to  warrant  a  new  registration,  if  the  parameter  is  only  applied  locally.  (We  will 
assume  that  this  is  the  case  for  this  example.) 

Change#2.  Suppose  the  same  attribute  is  to  be  deleted.  Then  some  assessment  is  needed,  regarding  the 
Impact  of  the  change  to  the  global  operational  environment  in  which  the  technical  object  is  to  function,  to 
determine  if  a  new  registration  is  required  with  a  new  01 D. 

The  relative  significance  of  the  two  changes  to  the  operational  requirements  are  clear  (given  our 
assumptions  here)  in  these  two  cases.  Changing  the  values  of  the  range  of  the  TIMEOUT  parameter  is  a 
relatively  minor  change  which  affects  only  local  operation.  Depending  on  other  operational  considerations, 
and  the  relation  of  the  TIMEOUT  to  other  facts  about  the  technical  object  it  could  be  changed  without  a  new 
registration.  But  the  elimination  of  the  TIMEOUT  attribute  altogether  would  be  much  more  significant,  and 
more  than  likely  require  a  new  registration,  since  current  implementations  would  be  expecting  the  existence 
of  such  an  attribute  in  any  operating  environment,  and  future  implementations  would  not  include  it. 


C.2.2       Evaluating  the  State  Values 

Within  the  registered  technical  object  description  there  may  be  a  number  of  constants,  ranges  of  values,  and 
syntaxes  specifically  defined  for  the  object.  They  are  all  subject  to  change.  The  evaluation  criteria  applied 
to  requests  for  changes  to  state  values  has  to  consider  the  kind  of  operation  that  the  technical  object  is 
performing. 

EXAMPLE:  The  range  of  accepted  values  is  changed  from  1-128  to  0-127,  or  the  default  value  of  a  parameter 
Is  changed  from  32  to  128. 

Understanding  the  implications  of  what  is  changing  helps  to  measure  the  impact  of  the  proposed  changes. 
The  shift  of  the  range  from  1-128,  to  0-127  could  be  trivial,  depending  on  the  scope  of  its  use  and  would 
not  alone  necessarily  warrant  a  new  registration.  However  to  change  a  default  value  from  32  to  128  (if  the 
attribute  applies  to  the  availability  or  limit  of  some  external  system  or  network  resource)  would  clearly  be 
cause  for  much  concern  over  how  the  cfiange  impacts  implementations  of  the  technical  object. 


C.2.3       Evaluating  the  Data  Structure 

Each  technical  information  object  may  have  one  or  more  data  structures  defined  within  the  description  of 
the  object.  Changes  can  be  made  to  the  data  structures  in  a  umber  of  ways.  Data  field  sizes  can  change, 
and  the  number  of  data  fields  can  change.  As  with  the  state  values,  they  should  be  considered  in  a  very 
broad  sense  that  is  within  the  definition  and  the  extent  of  the  use  of  these  data  structures  beyond  local 
system  usage. 
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One  must  be  aware  that  all  syntactical  changes  in  a  technical  definition  need  not  be  mandatory;  they  may 
be  optional.  Given  that  the  changes  are  mandatory,  they  are  most  likely  to  affect  every  implementation,  and 
are  going  to  impact  the  functioning  of  the  object.  Such  a  case  would  warrant  that  the  change  be  registered 
as  a  new  technical  object. 

EXAMPLE:  A  defined  data  field  is  changed  from  3  octets  to  4  and  another  field  is  reduced  from  2  octets  to 
1. 

Changing  the  data  structure  is  probably  the  clearest  case  of  a  requirement  to  change  an  implementation. 
One  must  be  aware  that  all  syntactical  changes  in  a  technical  definitions  need  not  be  mandatory,  they  may 
be  optional.  But  if  the  changes  are  mandatory,  they  will  most  likely  affect  every  implementation,  and  in  such 
a  way  that  they  will  not  interoperate  properly  with  old  implementations.  Such  cases  warrant  that  the  change 
be  registered  as  a  new  technical  object  with  a  new  OID. 

With  respect  to  applying  these  criteria,  it  should  be  emphasized  that  it  is  most  important  to  be  consistent 
in  making  subjective  judgments  concerning  changes  to  registered  technical  objects,  rather  than  being 
"correct." 

There  may  be  more  than  one  interpretation  or  'correct'  view  regarding  any  proposed  change,  but  if  the 
application  of  the  guidelines  are  consistent,  then  the  implementations  are  more  likely  to  be  consistent. 


C.3     The  Change  Process 

Responsibility  for  evaluating  the  change  requests  is  assigned  to  each  SIG.  The  SIG  makes  its  determinations 
by  voting  on  changes  to  each  registered  object  as  it  is  defined  in  the  SIG  text  in  the  OIW  Implementation 
Agreements  Documents.  Any  SIG  approved  changes  must  also  be  voted  in  the  OIW  Plenary  using  the  rules 
of  the  SIG  and  the  Plenary. 

An  object  definition  in  a  Working  Agreement  text  is  not  registered  until  it  has  been  voted  into  the  Stable 
Agreements  Document,  so  it  is  possible  to  modify  an  as  yet  "unregistered"  object  in  the  Working  Agreements 
Document. 
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given. 
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Part  7  CCITT  1984  X.400  Based  Message  Handling  System 


NOTE  -  The  classification  schema  used  in  this  chapter  (see  table  7)  pre-dated  TR  10  000  and  was  the 
basis  of  extensive  harmonization,  as  such:  No  attempt  will  be  made  to  align  this  chapter  with  TR  10  000. 


0  Introduction 

This  is  an  implementation  agreement  developed  by  the  Implementor's  Worl<shop  sponsored  by  the  U.S. 
National  Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of  data  between 
devices  manufactured  by  different  vendors.  This  agreement  is  based  on,  and  employs  protocols 
developed  in  accord  with,  the  OSI  Reference  Model.  While  this  agreement  introduces  no  new  protocols, 
it  eliminates  ambiguities  in  interpretations. 

This  is  an  implementation  agreement  for  a  Message  Handling  System  (MHS)  based  on  the  X.400-series 
of  Recommendations  (1984)  and  Version  5  of  the  X.400  Series  Implementor's  Guide  from  the  CCITT.  It  is 
recommended  that  product  vendors  consult  later  versions  of  this  guide.  Figure  1  displays  the  layered 
structure  of  this  agreement. 

This  agreement  can  be  used  over  any  Transport  protocol  class.  In  particular,  this  MHS  agreement  can 
be  used  over  the  Transport  protocol  class  0  used  over  CCITT  X.25,  described  in  clause  5.2  of  this 
document.  In  addition,  this  MHS  agreement  can  be  used  over  the  Transport  profiles  used  in  support  of 
MAP  (Manufacturing  Automation  Protocol)  or  TOP  (Technical  and  Office  Protocols).  Note  that  the  MAP 
or  TOP  environment  must  support  the  reduced  Basic  Activity  Subset  (BAS)  as  defined  in  X.410. 

The  UAs  and  MTAs  require  access  to  directory  and  routing  sen/ices.  A  Directory  Service  is  to  be 
provided  for  each  (vendor-specific)  domain.  Except  insofar  as  they  must  be  capable  of  providing 
addressing  and  routing  described  hereunder,  these  services  and  associated  protocols  are  not  described 
by  this  agreement. 


User  Agent  Layer 

CCITT  X.420 

Message  Transfer  Agent  Layer 

CCITT  X.411 

Reliable  Transfer  Service  Layer 

CCITT  X.410 

Presentation  Layer 

CCITT  X.410  Sec.  4.2 

Session  Layer 

See  clause  5.9 

Figure  1  -  The  layered  structure  of  this  implementation  agreement. 
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1  Scope 

This  agreement  applies  to  Private  Management  Domains  (PRIVIDs)  and  Administration  l\/lanagement 
Domains  (ADMDs).  Four  boundary  interfaces  are  specified: 

a)  PRMDtoPRMD, 

'      •   b)  PRMD  to  ADMD, 

c)  ADIVID  to  ADIVID,  and 

d)  IVITA  to  MTA  (within  a  PRIVID,  e.g.,  for  IVITAs  from  different  vendors). 

In  case  A.  the  PRMDs  do  not  make  use  of  MHS  services  provided  by  an  ADMD.  In  cases  B  and  C,  UAs 
associated  with  an  ADMD  can  be  the  source  or  destination  for  messages.  Furthermore,  in  cases  A  and 
B,  a  PRMD  can  serve  as  a  relay  between  MDs,  and  in  cases  B  and  C  an  ADMD  can  serve  as  a  relay 
between  MDs.  Figure  2  illustrates  the  interfaces  to  which  the  agreement  applies. 

X.400  protocols  other  than  the  Message  Transfer  Protocol  (P1)  and  the  Interpersonal  Messaging 
Protocol  (P2)  are  beyond  the  scope  of  this  agreement.  Issues  arising  from  the  use  of  other  protocols  or 
relating  to  PI  components  in  support  of  other  protocols  are  outside  the  scope  of  this  document.  This 
agreement  describes  the  minimum  level  of  services  provided  at  each  interface  shown  in  figure  2. 
Provision  for  the  use  of  the  remaining  services  defined  in  the  X.400  Series  of  Recommendations  is 
outside  the  scope  of  this  document. 

With  the  exception  of  intra  domain  connections,  this  agreement  does  not  cover  message  exchange 
between  communicating  entities  within  a  domain  even  if  these  entities  communicate  via  P1  or  P2. 
Bilateral  agreements  between  domains  may  be  implemented  in  addition  to  the  requirements  stated  in 
this  document.  Conformance  to  this  agreement  requires  the  ability  to  exchange  messages  without 
use  of  bilateral  agreements. 
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PRMD  =  Private  Management  Domain 

ADMD  =  Administration  Management  Domain 


PRMD 


MTA 

A 

 D 

MTA 

B 

PRMD 


I 
I 

A 


 A 


PRMD 


I 
I 
I 
I 

B 


 B 


ADMD 


 C 


ADMD 


Figure  2  -  This  agreement  applies  to  the  interface  between:  (A)  PRIVID  and  PRIVID;  (B)  PRMD  and 
ADIVID;  (C)  ADMD  and  ADMD;  and  (D)  MTA  and  MTA. 


2     Normative  References 

CCITT  Recommendation  X.121  (1988),  International  Numbering  Plan. 

CCITT  Recommendation  X.400,  (Red  Book,  1984),  Message  Handling  Systems:  System  Model-Service 
Elements. 

CCITT  Recommendation  X.401,  (Red  Book,  1984),  Message  Handling  Systems:  Basic  Service  Elements 
and  Optional  User  Facilities. 

CCITT  Recommendation  X.408,  (Red  Book,  1984),  Message  Handling  Systems:  Encoded  Information 
Type  Conversion  Rules. 

CCITT  Recommendation  X.409,  (Red  Book,  1984),  Message  Handling  Systems:  Presentation  Transfer 
Syntax  and  Notation. 

CCITT  Recommendation  X.410,  (Red  Book,  1984),  Message  Handling  Systems:  Remote  Operations  and 
Reliable  Transfer  Server. 

CCITT  Recommendation  X.411,  (Red  Book,  1984),  Message  Handling  Systems:  Message  Transfer  Layer. 

CCITT  Recommendation  X.420,  (Red  Book,  1984),  MessageHandling  Systems:  Interpersonal  Messaging 
User  Agent  l_ayer. 

CCITT  Recommendation  X.430,  (Red  Book,  1984),  Message  Handling  Systems:  Access  Protocol  for 
Teletex  Terminals. 
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This  version  of  the  X.400  based  Message  Handling  System  implementation  agreements  was  completed 
on  December  16,  1988.  No  further  enhancements  will  be  made  to  this  version.  See  the  next 
clause-Errata. 


4  Errata 

5  PRMD  to  PRMD 

5.1  Introduction 


This  clause  is  limited  in  scope  to  issues  arising  from  the  direct  connection  (interface  A  in  figure  2)  of  two 
PRMDs.  "Direct"  means  that  no  ADMD  or  relaying  PRMD  provides  MHS  services  to  facilitate  message 
interchange.  "Direct"  does  not  exclude  those  instances  for  which  Administrations  happen  to  be  ADMDs 
but  are  not  providing  X.400  sen/ices,  that  is,  they  are  used  only  to  provide  lower  layer  services  such  as 
X.25.  Figure  3  schematically  represents  the  scope  of  this  clause. 

These  issues  relate  to  the  use  of  the  UAL  (User  Agent  Layer)  and  MTL  (Message  Transfer  Layer) 
services,  protocol  elements,  recommended  practices  and  constraints.  In  particular,  this  clause  addresses 
the  P1  and  P2  protocols  and  their  related  services  in  a  direct  connection  environment.  This  clause 
describes  the  minimum  level  of  services  provided  by  a  PRMD.  Provision  for  the  use  of  the  remaining 
services  defined  in  the  X.400  Series  of  Recommendations  is  beyond  the  scope  of  this  clause. 


Private  Domain  X 


I— > 


UA 


MTA 


the 

remainde L 
iiiDomain  X 

of  ;|| 

P2 
PI 


Private 

Domain  Y 

UA 

<— 

 > 

MTA 

 > 

/ 

\ 

the 
^remainder 
i Domain  Y 

NETWORK 

of 

Figure  3  -  Interconnection  of  private  domains. 


4 


Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 

5.2      Service  Elements  and  Optional  User  Facilities 

This  clause  identifies  tliose  service  elements  and  optional  user  facilities  that  must  be  provided  in  support 
of  P1  and  P2. 

5.2.1       Classification  of  Support  for  Services 

The  classification  of  UA  and  MT-Service  elements  is  used  to  define  characteristics  of  equipment. 
Equipment  can  claim  SUPPORT  or  NON-SUPPORT  of  a  Service;  in  the  case  of  UA-service  elements,  a 
separate  classification  is  given  for  Origination  and  Reception. 

The  service  provider  is  defined  as  the  entity  providing  the  service,  in  this  case,  the  MTL  or  the  UAL.  The 
service  user  is  either  the  MHS  user  or  the  UAL.  The  classification  of  provider  and  user  relates  to  the 
sublayer  for  which  the  service  element  is  defined. 

5.2.1.1         Support  (S) 

Support  means: 

a)  The  service  provider  makes  the  service  element  available  to  the  service  user,  and 

b)  The  service  user  gives  adequate  support  to  the  MHS  to  invoke  the  service  element  or  makes 
information  associated  with  the  service  element  available. 

Support  for  Origination  means  that: 

a)  The  service  provider  makes  the  service  element  available  to  the  service  user  for  invocation, 
and 

b)  The  service  user  gives  adequate  support  to  the  end  user  of  the  MHS  to  invoke  the  service 
element. 

Support  for  Reception  means  that: 

a)  The  service  provider  makes  information  associated  with  the  service  element  available  to  the 
service  user. 

NOTE  -  A  UA-  or  MT-service  element  can  carry  information  from  originator  to  recipient  only  if: 

b)  the  service  element  is  available  to  the  originator, 

c)  the  service  element  is  available  to  the  recipient,  and 

d)  all  intermediate  steps  carry  the  information. 
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5.2.1.2         Non  Support  (N) 

This  means  that  the  service  provider  is  not  required  to  make  the  service  element  available  to  the  service 
user.  However,  the  service  provider  should  not  regard  the  occurrence  of  the  corresponding  protocol 
elements  as  an  error  and  should  be  able  to  relay  such  elements.  Implementations  making  a  profile 
available  should  indicate  deviations  (additions  or  deletions)  with  respect  to  the  requirement  in  the  profile. 


5.2.1.3  Not  Used  (N/U) 

This  means  that  although  the  Recommendation  allows  this  service  element,  this  profile  does  not  use  it. 

5.2.1.4  Not  Applicable  (N/A) 

This  means  that  this  service  element  does  not  apply  in  this  particular  case  (for  originator  or  recipient). 


5.2.2       Summary  of  Supported  Services 

Within  a  PRMD,  a  User  Agent  must  support  all  P2  BASIC  IPM  Services  (X.400)  and  all  P2  ESSENTIAL 
IPM  Optional  user  facilities  (X.401)  subject  to  the  qualifiers  listed  in  annex  A. 

Within  a  PRMD,  a  MTA  must  support  all  BASIC  MT  Services  (X.400)  and  all  ESSENTIAL  MT  optional 
user  facilities  (X.401)  subject  to  the  qualifiers  listed  in  annex  A. 

No  support  is  required  of  the  additional  optional  user  facilities  of  X.401. 


5.2.3       MT  Service  Elements  and  Optional  User  Facilities 

Tables  1  through  3  show  the  Message  Transfer  (MT)  service  elements  and  optional  user  facilities. 

Table  1  -  Basic  MT  Service  Elements 


Support  (S)  or 
Service  Elements  Non-support  (N) 


Access  Management 

N/U^ 

Content  Type  Indication 

S 

Converted  Indication 

S 

Delivery  Time  Stamp  Indication 

S 

Message  Identification 

S 

Non-delivery  Notification 

S 

Original  Encoded  Information  Types  Indication 

s  , 

Registered  Encoded  Information  Types 

N/U^ 

Submission  Time  Stamp  Indication 

S 

Notes 

1    Not  applicable  to  co-resident  UA  and  MTA. 
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Table  2  -  MT  Optional  User  Facilities  Provided  to  the  UA-Selectable  on  a  Per-Message  Basis 


Support  (S)  or 

MT  Optional  User  Facilities  Categorization    Non-support  (N) 


Alternate  Recipient  Allowed 

E 

S 

Conversion  Prohibition 

E 

Deferred  Delivery 

E 

k 

Deferred  Delivery  Cancellation 

E 

Delivery  Notification 

E 

Disclosure  of  Other  Recipients 

E 

^3 

Explicit  Conversion 

A 

N 

Grade  of  Delivery  Selection 

E 

S 

Multi -destination  Delivery 

E 

S 

Prevention  of  Non-delivery  Notification 

A 

Probe 

E 

n4 

Return  of  Contents 

A 

N 

Legend 

E:    Essential  optional  user  facility. 
A:    Additional  optional  user  facility. 


Notes 

2  A  local  facility  subject  to  qualifiers  in  annex  A. 

3  Support  not  required  for  an  originating  MT  user;  support  must  be 
provided  for  recipient  MT  users. 

4  Subject  to  qualifiers  in  annex  A. 


Table  3  -  MT  Optional  User  Facilities  Provided  to  the  UA  Agreed  for  Any  Contractual  Period  of 

Time 


MT  Optional  User  Facilities  Categorization 

Support  (S)  or 
Non-Support  (N) 

Alternate  Recipient  Assignment  A 
Hold  for  Delivery  A 
Implicit  Conversion  A 

N 

N/U 
N 

Legend 

A:     Additional  optional  user  facility. 

5.2.4       IPM  Service  Elements  and  Optional  User  Facilities 

Tables  4  through  6  show  the  IPM  sen/ice  elements  and  optional  user  facilities. 
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Table  4  -  Basic  iPM  service  eiements 


Origination 

Reception 

Service  Elements 

by  UAs 

by  UAs 

Access  Management 

N/U^ 

N/U^ 

Content  Type  Indication 

S 

Converted  Indication 

N/A 

S 

Delivery  Time  Steimp  Indication 

N/A 

S 

Message  Identification 

S 

s 

Non-delivery  Notification 

S 

N/A 

Original  Encoded  Information 

s 

S 

Types  Indication 

Registered  Encoded  Information  Types  N/A 

N/A^ 

Submission  Time  Stamp  Indication 

S 

S 

IP-message  Identification 

S 

S 

Typed  Body 

s 

S 

Notes 

5    Does  not  apply  to  co-resident 

UA  and  MTA. 

Table  5  -  IPM  Optional  Facilities  Agreed  for  a  Contractual  Period  of  Time 


Support  (S)  or 

Service  Elements  Categorization 

Non-Support  (N) 

Alternate  Recipient  Assignment  A 

N 

Hold  for  Delivery  A 

N 

Implicit  Conversion  A 

N 
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Table  6  -  IPM  Optional  User  Facilities  Selectable  on  a  Per-Message  Basis 


Origination 

Reception 

IPM  Optional  User  Facilities 

by  UAs 

by  UAs 

Aiternaue  Kecipieniz  Axxoweu 

A 

(N) 

"     ^  IN  ; 

Aurnorizxny     users  xnaication 

A 

(N) 

E  (S) 

fiuro— Eorwaraea  inaicauion 

A 

(N) 

E  (S) 

Blind  Copy  Recipient  Indication 

A 

(N) 

E  (S) 

Doay  irarr  r<ncryption  inaicaizion 

A 

(N) 

E  (S) 

v^onv6iSi.Qn  IT L on  1  o  1  L 1  on 

E 

(S) 

E  (S) 

cross— rererenciny  inaicaLion 

A 

(N) 

E  (S) 

E 

N/A 

uererrea  oexivery  v^ancexxation 

a 
t\ 

<  M  At  ^ " 

N/A 

Delivery  Notification 

E 

(S) 

N/A 

Disclosure  of  Other  Recipients 

A 

(N) 

E  (S) 

fiXpiry  uate  maicarion 

A 

(N) 

E  (S) 

£<xpxiciT.  conversion 

A 

(N) 

N/A 

rorwaraeu  xit'— niessaye  xnaicacion 

A 

(N) 

E  (S) 

Gr^dB  of  Del i  vsry  Select  ion 

E 

(S) 

E  (S) 

Xm^AjL  X,aIXC6    XIlU  1         L  1  Oil 

A 

(N) 

E  (S) 

nux  u  1  — aes  c i iia u  x on       x x very 

E 

(S) 

N/A 

wuiui— part  uoay 

A 

(N) 

E  (S) 

won— receipr  iMonricarion 

a 

f  N^ 

A  (N) 

Obsoleting  Indication 

A 

(N) 

E  (S) 

uriyinaror  inaicarion 

E 

(S) 

E   f S) 

Prevention  of  Non-delivery  Notification 

A 

(N) 

N/A 

Primary  and  Copy  Recipients  Indication 

E 

(S) 

E  (S) 

Probe 

(N) 

N/A 

Receipt  Notification 

A 

(N) 

A  (N) 

Reply  Request  Indication 

A 

(N) 

E  (S) 

Replying  IP-message  Indication 

E 

(S) 

E  (S) 

Return  of  Contents 

A 

(N) 

N/A 

Sensitivity  Indication 

A 

(N) 

E  (S) 

Subject  Indication 

E 

(S) 

E  (S) 

Notes 

6    A  local  facility  subject  to  qualifiers  in  annex 

A. 

5.3      X.400  Protocol  Definitions 

This  clause  reflects  the  agreements  of  the  OIW  regarding  P1  and  P2  protocol  elements. 

5.3.1       Protocol  Classification 

The  protocol  classifications  are  defined  in  table  7. 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 

Table  7  -  Protocol  Classifications 


1)  UNSUPPORTED  =  X 

These  elements  may  be  generated,  but  no  specific  processing  should 
be  expected  in  a  relaying  or  delivering  domain.  A  relaying  domain 
must  at  least  relay  the  semantics  of  the  element.  The  absence  of 
these  elements  should  not  be  assumed,  in  a  relaying  or  delivering 
domain,  to  convey  any  significance. 

2)  SUPPORTED  =  H 

These  elements  may  be  generated.  However,  implementations  are  not 
required  to  be  able  to  generate  these  elements.  Appropriate 
actions  shall  be  taken  in  a  relaying  or  delivering  domain. 

3)  GENERATABLE  =  G 

Implementations  must  be  able  to  generate  and  handle  these  protocol 
elements,  although  they  are  not  necessarily  present  in  all 
messages  generated  by  implementations  of  this  profile. 
Appropriate  actions  shall  be  taken  in  a  relaying  or  delivering 
domain. 

4)  REQUIRED  =  R 

Implementations  of  this  profile  must  always  generate  this  protocol 
element.  However,  its  absence  cannot  be  regarded  as  a  protocol 
violation  as  other  MHS  implementations  may  not  require  this 
protocol  element.  Appropriate  actions  shall  be  taken  in  a 
relaying  or  delivering  domain. 

5)  MANDATORY  =  M 

This  must  occur  in  each  message  as  per  X.411  or  X.420  as 
appropriate;  absence  is  a  protocol  violation.  Appropriate  actions 
shall  be  taken  in  a  relaying  or  delivering  domain. 


5.3.2       General  Statements  on  Pragmatic  Constraints 

Where  a  protocol  element  is  defined  as  a  choice  of  Numeric  String  and  Printable  String  (i.e., 
Administration  Domain  Name  and  Private  Domain  Identifier),  then  a  numeric  value  encoded  as  a 
printable  string  is  equivalent  to  the  same  value  encoded  as  a  numeric  string.  This  does  not  apply  to  the 
Country  Name  protocol  element. 

The  maximum  number  of  recipients  in  a  single  MPDU  is  32K  -  1  (that  is,  32767).  However,  no  individual 
limits  on  the  number  of  occurrences  (recipients)  are  placed  on  the  following  protocol  elements: 
Authorizing  Users,  Primary  Recipients,  Copy  Recipients,  Blind  Copy  Recipients,  Obsoletes  and  Cross 
References.  Additionally,  there  is  no  limit  on  the  number  of  Reply  to  Users.  This  is  a  local  matter  for  the 
originating  system. 

Use  of  strings.  A  Printable  String  is  defined  in  terms  of  the  number  of  characters,  which  is  the  same 
number  of  octets.  For  T.61  strings  the  number  of  octets  is  twice  the  number  of  characters  specified. 

The  ability  to  generate  maximum  size  elements  is  not  required,  with  the  exception  of  the  component 
fields  in  the  Standard  Attribute  List,  in  which  case  it  is  required. 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 

5.3.3  MPDU  Size 

The  following  agreements  govern  the  size  of  MPDUs: 

a)  AJI  MTAEs  must  support  at  least  one  MPDU  of  at  least  2  megabyte,  and 

b)  The  size  of  the  largest  MPDU  supported  by  a  UAE  is  a  local  matter. 

5.3.4  PI  Protocol  Elements 

Table  8  contains  Protocol  Elements  and  their  classes. 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 


Table  8  -  Pi  Protocol  Elements 


El  PinpTii" 

Class 

Rpsi" T i pI"  i mi^  and  CoTninpnt* q 

MPDU 

UserMPDU 

G 

DeliveryReportMPDU 

G 

'  ProbeMPDU 

H 

UserMDPU 

UMPDUEnvelope 

M 

UMPDUContent 

M 

UMPDUEn ve 1 ope 

MPDUIdentif ier 

M 

originator  ORname 

M 

or iginalEncodedlnformationTypes 

G 

If  this  field  is  absent,  then  the 

Encoded  Information  Type  is 

"unspecified. " 

Content Type 

M 

UAContentID 

H 

Maximum  length  =  16  characters. 

Priority 

G 

PerMessageFlag 

G 

Maximum  length  =  2  octets. 

def err edDeli very 

X 

PerDomainBi lateral Info 

X 

No  limit  on  number  of  occurrences. 

Recipientinf o 

M 

Maximum  number  =  32K  -  1  occurr- 

ences. More  severe  limitations  are 

by  bilateral  agreement. 

Traceinf ormation 

M 

UMPDUContent 

M 

MPDUIdentif ier 

GlobalDomainldentif ier 

M 

lASString 

M 

Maximum  length  =  32  characters, 

graphical  subset  only.    Refer  to 

T.50  for  clarification  of  graphical 

PerMessageFlag 

subset . 

discloseRecipients 

H 

conversionProhibited 

G 

alternateRecipient Allowed 

H 

contentReturnRequest 

X 

Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 


Table  8  -  Pi  Protocol  Elements  (continued) 


Element 

Class 

Restrictions  and  Comments 

PerDomainBilaterallnfo 

Count  ryNeune 

M 

Maximum  length  =  3  characters. 

Adm  inistrati  onDoma  i  nName 

M 

Maximum  length  =  16  characters. 

Bilaterallnfo 

M 

Maximiim  depth  =  8;  maximum 

length  =  1024  octets 

(including  encoding). 

Recipient Info 

recipient 

M 

Extensionldentif ier 

M 

Maximum  value  =  32K  -  1  (32767). 

perRecipientFlag 

M 

Maximum  length  =  2  octets. 

ExplicitConversion 

X 

perRecipientFlag 

ResponsibilityFlag 

M 

ReportRequest 

M 

UserReportRequest 

M 

Traceinf ormat  ion 

Reference  should  be  made  to 

Version  5  of  the  X.400  Imple- 

mentor's  Guide  for  information 

GlobalDomainldentif ier 

M 

related  to  Trace  sequencing. 

Doma  i  nSuppl i  edi nf o 

M 

DomainSuppl iedlnfo 

arrival 

M 

deferred 

X 

action 

M 

0=relayed  (value) 

G 

l=rerouted  (value) 

H 

Rerouting  is  not  required. 

converted 

H 

previous 

H 

ORName 

See  clause  5.3.5 

Encodedinf ormat  ionTypes 

bit  string 

M 

Delivery  can  only  occur  if  match 

is  made  with  Registered  Encoded 

Information  Types.  Individual 

vendors  may  impose  limits. 

Maximum  length  =  4  octets. 

G3NonBasicParameters 

X 

TeletexNonBasicParameters 

X 

Presentat  ionCapabi 1 i  t  i  es 

X 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 


Table  8  -  PI  Protocol  Elements  (continued) 


Element 

Class 

Restrictions  and  Pomnipnl""? 

De 1 i  ve  r yRepor  tMPDU 

DeliveryReportEnvelope 

M 

DeliveryReportContent 

M 

DeliveryReportEnvelope 

report 

M 

originator 

M 

Tracelnformation 

M 

Del i veryRepor tContent 

original 

M 

intermediate 

G 

See  comment  at  end  of  table. 

UAContentID 

G 

ReportedRecipientlnfo 

M 

Maximum  number  =  32K  -  1 

occurrences . 

returned 

H 

Can  only  be  issued  if  specifically 

requested  in  the  originating 

message. 

billinginf ormation 

X 

Maximum  depth  =  8;  maximum 

length  =  1024  octets  (including 

encoding ) , 

ReportedRecipientlnfo 

recipient 

M 

Extensionsldentif ier 

M 

PerRecipientFlag 

M 

Las tTraceInf ormation 

M 

intendedRecipient 

H 

Supplementaryinf ormation 

X 

Maximum  length  =  64  characters. 

Value  is  pending  verification  by 

the  CCITT  SG  VIII  or  XI. 

Las tTraceInf ormat  ion 

arrival 

M 

converted 

G 

Report 

M 

i; 

M 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 


Table  8  -  Pi  Protocol  Elements  (concluded) 


Class      Restrictions  and  Comments 

Report 

Deliveredlnfo 
Nondeliveredlnfo 

Deliveredlnfo 
delivery 
typeofUA 

G 
G 

M 
R 

Generated  if  delivery  is  reported. 
Generated  if  failure  to  deliver 
is  reported. 

This  element  must  be  generated  with 
a  PRIVATE  value  by  PRMDs. 

NonDeliveredlnfo 
ReasonCode 
DiagnosticCode 

M 
H 

Whenever  possible,  use  a  meaningful 
diagnostic  code. 

ProbeEnvelope 

originator 
Pon  t  pn  t  T VDP 
UAContentID 
original 

M 
M 
M 
H 
G 

Maximum  length  =  16  characters. 
If  this  field  is  absent,  then  the 
Encoded  Information  Type  is 
"unspecified. " 

Traceinf ormat  ion 

M 

PprMps  saopPl an 

G 

contentLength 
PerDomainBi lateral Info 
Recipient Info 

f^T  oVia  1  "n^^tna  inTHPTTf"!  or* 

\J.l.\JL/a^U\JUlCi  ±111.  UCIX  L  X  L  X 

Count ryName 

Adm  inistrati  onDoma  i  nName 

(4) 

H 
X 
M 

M 
M 

Maximum  number  =  32K  -  1 
occurrences. 

Maximum  length  -  3  characters. 
Maximum  length  =  16  characters  or 
digits . 

PrivateDomainldentif ier 

R 

Maximum  length  =  16  characters  or 
digits.     This  element  must  be 
generated  by  PRMDs. 

End 

of  Definitions 

Notes 

Coiament  on  intermediate  Tracelnformation  in  the  DeliveryReportContent  in 
table  8:    Audit  and  confirmed  reports  should  not  be  requested    by  other 
than  the  originating  domain  for  two  reasons.  First,  the  return  path  of 
the  report  may  be  different  from  the  path  taken  by  the  original  message, 
and  it  may  exclude  the  domain  that  added  the  request  for  audit  and 
confirmed  to  the  message.  Second,  if  the  return  path  is  different  from 
the  path  of  the  original  message,  the  originating  domain  would  receive 
intermediate  trace  information  that  it  did  not  request. 
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Part  7: 1984  Message  Handling  Systems 


December  1991  (Stable) 


5.3.5       ORName  Protocol  Elements 

Only  form  1  variant  1  0/R  nannes  are  supported. 
Table  9  contains  ORName  protocol  elements. 

These  agreements  interpret  1984  X.400  clause  3.4  to  mean  that  the  attributes  in  the  ORName  in  the 
MPDU  must  identify  exactly  one  UA,  and  that  all  the  values  for  the  attributes  specified  in  the  ORName 
must  be  identical  to  the  values  of  the  corresponding  attributes  associated  with  the  recipient  UA. 
Underspecified  names  that  are  unique  are  deliverable. 

Overspecified  ORNames,  ORNames  with  mismatching  fields,  and  ambiguous  names  are  to  be  non- 
delivered  or  sent  to  the  alternate  recipient  as  appropriate. 


Table  9  -  ORName  Protocol  Elements 


Element 

Class 

Restrictions  and  Comments 

ORName 

StandardAttributeList 

M 

II      DomainDef  inedAttributeList 

G 

1 
1 

StanaardAttr ibuteList  (1) 

Count ryName 

R 

As  defined  in  X.411,  Maximum 

length  =  3  characters. 

Administrat lonDomainName  (4) 

R 

Maximum  length  =  16  characters 

or  digits. 

X121Address 

X 

Maximum  length  =  15  digits. 

TerminallD 

X 

Maximum  length  =  24  characters. 

PrivateDomainName  (2) 

G 

Maximum  length  =  16  characters. 

OrganizationName  (2) 

G 

Maximum  length  =  64  characters. 

UniqueUAIdentif ier 

X 

Maximtim  length  =  32  digits. 

PersonalName 

G 

Maximum  length  of  values  of  sub- 

elements  =  64  characters. 

Note:     The  possibility  that  this 

value  may  be  reduced  to  40 

characters  is  for  further 

study  by  the  CCITT. 

OrganizationalUnit  (3) 

G 

Maximum  length  =  32  characters  per 

occurrence.     A  maximum  of  four 

occurrences  are  allowed. 

DomainDef inedAttributeList  (5) 

Maximum  =  4  occurrences. 

type 

M 

Maximum  length  =  8  characters. 

value 

M 

Maximum  length  =  128  characters. 

PersonalName 

surName 

M 

Maximum  length  =  40  characters. 

givenName 

G 

Maximum  length  =  16  characters. 

initials 

G 

Maximum  length  =    5  characters; 

excluding  surname  initial  and 

punctuation  and  spaces. 

generat ionQualif ier 

G 

Maximum  length  =  3  characters. 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 

Table  9  -  ORName  Protocol  Elements  (concluded) 


Notes ; 

1  The  following  apply  for  comparison  of  the  Standard  Attributes  of  an 
0/R  Name: 

a)  Lower  case  is  interpreted  as  upper  case  (for  IA5). 

b)  Multiple  spaces  may  be  interpreted  as  a  single  space.  Originating 
domains  shall  only  transmit  single  significant  spaces.  If  multiple 
spaces  are  transmitted,  non-delivery  may  occur. 

2  At  least  one  of  these  must  be  supplied. 

3  These  should  be  sent  in  descending  sequence,  from  the  most  significant 
<Organizational  Unit>  (highest  in  organization  hierarchy)  to  the  least 
significant.  Only  those  specified  should  be  sent.  (That  is,  an 
unspecified  <Organizational    Unit>  should  not  be  sent  along  as  a  field 
of  [null]  content,  nor  zero  length,  etc.) 

4  This  attribute  shall  contain  one  space  in  all  ORNames  of  messages 
originated  in  a  PRMD  that  is  not  connected  to  an  ADMD,  and  in  ORNames 
of  recipients  reachable  only  through  a  PRMD;  otherwise,  this  attribute 
shall  contain  an  appropriate  ADMD  name. 

5  Some  existing  systems  which  will  be  accessed  via  an  X.400  service 
(whether  directly  connected  using  X.400  protocols  or  otherwise)  may 
require  the  provision  of  addressing  attributes  which  are  not  adequately 
supported  by  Standard  Attributes  as  defined  in  these  Agreements.  In 
such  cases.  Domain  Defined  Attributes  are  an  acceptable  means  of 
carrying  additional  addressing  information.  Failure  to  support  the 
specification  and  relaying  of  DDAs  may  prevent  successful  interworking 
with  such  existing  systems  until  such  time  as  all  systems  are  capable 
of  relaying  and  delivery  using  only  the  Standard  Attribute  list. 
Specific  recommendations  on  the  use  of  DDAs  for  particular  applications 
are  in  the  Recommended  Practices,  annex  B. 


5.3.6       P2  Protocol  Profile  (Based  on  [X.420]) 

Tables  10  and  11  classify  the  support  for  the  P2  protocol  elements  required  by  this  profile.  The  tables 
give  restrictions  and  comments  in  addition  to  X.420. 

Restriction  on  length  is  one  of  the  types  of  restrictions.  The  reaction  of  implementations  to  a  violation  of 
this  restriction  is  not  defined  by  this  Profile. 


5.3.6.1         P2  Protocol  -  Heading 

Table  10  specifies  the  support  for  protocol  elements  in  P2  Headings. 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 


Table  10  -  P2  Heading  Protocol  Elements 


Element 

Class 

Restrictions  and  Comments 

UAPDU 

IM-UAPDU 

G 

SR— UAPDU 

X 

IM-UAPDU 

Heading 

M 

Body 

M 

Heading 

iPMessagelu 

M 

originator 

R 

author  i  z  ingUser s 

H 

pr  imaryRecipients 

G 

At  least  one  or  primaryRecipients , 

copyRec  i  p  i  en t  s 

G 

copyRec i pi ent s ,  or 

bli ndCopyRec i pi ent s  must  be 

bl 1 ndCopyRec i p i ent  s 

TT 

n 

present . 

inReplyTo 

G 

obsoletes 

H 

crossRef erences 

H 

subject 

G 

Maximum  length  =  128  T,61 

characters  (256  octets); the  ability 

to  generate  the  maximum  size 

subject  is  not  required. 

expiryDate 

H 

replyBy 

H 

replyToUsers 

H 

importance 

H 

Appropriate  action  is  for  further 

study. 

sensitivity 

H 

Appropriate  action  is  for  further 

study. 

autoforwarded 

H 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 


Table  10  -  P2  Heading  Protocol  Elements  (continued) 


Element 

Class 

Restrictions  and  Comments 

IPmessageld 

ORName 

H 

Print ablest ring 

M 

Maximum  length  =  64  characters. 

ORDescriptor 

ORName 

H 

Specify  the  ORName  whenever  it  is 

possible.     See  annex  B. 

freeformNcime 

H 

Maximum  length  =  64  characters, 

graphical  subset  only  (128  octets.) 

t  e 1 ephoneNumbe  r 

H 

Maximum  length  =  32  characters. 

This  allows  for  punctuation.  It 

does  not  take  into  account  possible 

future  use  by  ISDN. 

Recipient 

ORDescriptor 

M 

reportRequest 

X 

replyRequest 

H 

Body 

No  limit  on  number  of  BodyParts. 

BodyPart 

G 

No  limit  on  length  of  any  BodyPart 

or  the  depth  of  ForwardedlPMessage 

BodyParts  nested.  Classification  is 

subject  to  pending  CCITT  resolution 

SR-UAPDU 

nonReceipt 

H 

receipt 

H 

reported 

M 

actualRecipient 

R 

i  nt endedRec  i  p  i  ent 

H 

converted 

X 

NonReceipt Information 

reason 

M 

nonReceiptQualif ier 

H 

comments 

H 

Maximum  length  =  256  characters. 

returned 

H 

May  only  be  issued  if  specifically 

requested  by  originator. 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 


Table  10  -  P2  Heading  Protocol  Elements  (concluded) 


Element 

Class 

Restrictions  and  Comments 

Receipt Information 

receipt 

M 

typeOfReceipt 

H 

Supplement arylnformat  ion 

X 

Maximum  length  =  64  characters. 

Note:    This  value  is  pending 

verification  by  the  CCITT  SG 

VIII  or  IX. 

End 

o£  Definitions 

5.3.6.2        P2  Protocol  -  BodyParts 


5.3.6.2.1  BodyPart  Identifiers 

All  BodyParts  with  identifiers  in  the  range  0  up  to  and  including  16K  -1  are  legal  and  should  be  relayed. 
BodyPart  identifiers  corresponding  to  X.I 21  Country  Codes  should  be  interpreted  as  described  in  Note  2 
of  figure  4. 

a)  Implementations  are  required  to  generate  and  image  lASText. 

i1         b)  Implementations  should  specify  the  other  BodyPart  types  supported. 

c)  If  an  implementation  supports  a  particular  BodyPart  type  for  reception,  it  should  also  be  able 
j!         to  support  that  BodyPart  type  for  reception  if  it  is  part  of  a  ForwardedlPMessage. 

ly , 

I         d)  For  the  BodyPart  types  currently  considered,  support  for  the  protocol  elements  is  as 
ij         indicated  in  table  11. 


5.3.6.2.2  Privately  Defined  BodyParts 

This  clause  describes  an  interim  means  for  identifying  privately  defined  BodyParts.  This  clause  shall  be 
replaced  in  a  future  version  taking  into  account  CCITT  recommendations  with  equivalent  functionality. 
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Part  7:  1984  Message  Handling  Systems 


December  1991  (Stable) 


BodyPart  : :  =    CHOICE  { 

[0]  IMPLICIT  lASText, 
[1]   IMPLICIT  TLX, 


234]  IMPLICIT  UKBodyParts, 


310]  IMPLICIT  USABodyParts, 


} 

—  Where  UKBodyParts  and  USABodyParts  are  defined  as: 

SEQUENCE  {  BodyPartNumber ,  ANY  } 
BodyPartNumber  :;=  INTEGER 


Notes 

1  In  the  EncodedlnformationTypes  of  the  PI  Envelope,  the 
undefined  bit  must  be  set  when  a  message  contains  a 
privately  defined  BodyPart.  Each  UA  that  expects  such 
BodyParts  should  include  undefined  in  the  set  of 
deliverable  EncodedlnformationTypes  it  registers  with  the 
MTA. 

2  All  Body Part Numbers  assigned  must  be  interpreted  relative 
to  the  BodyPart  in  which  they  are  used,  which  is  that 
tagged  with  the  value  [310]  for  those  defined  within  the 
United  States.  The  NIST  assigns  unique  message 
BodyPartNumbers  for  privately  defined  formats  within  the 
United  States. 

3  Refer  to  clause  12.6  for  recommendations  regarding  the 
implementaion  of  USABodyParts. 


Figure  4  -  X.409  Definition  of  Privately  Defined  BodyParts. 


5.3.6.3        P2  BodyPart  Protocol  Elements 
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Table  11  -  P2  BodyParts 


Elements 

Class 

Restrictions  and  Comments 

BodyPart 

lASText 

G 

TLX 

X 

Voice 

X 

G3Fax 

X 

TIFO 

X 

TTX 

X 

Videotex 

X 

NationallyDefined 

X 

Encrypted 

X 

ForwardedlPMessage 

H 

SFD 

X 

TIFl 

X 

unidentified 

X 

lASText 

repertoire 

H 

lASString 

M 

For  rendition  of  lASText  see 

annex  C. 

TLX 

For  further  study  by  CCITT. 

Voice 

Set 

For  further  study  by  CCITT. 

BitString 

M 

G3Fax 

numberOf Pages 

X 

PI .G3NonBasicParameters 

X 

SEQUENCE   (OF  BIT  STRING) 

M 

BIT  STRING 

H 

See  Note. 

PI .GSNonBasicParameters 

Support  for  individual  elements  is 

for  further  study. 

TIFO 

T.73Document 

M 

T . 73ProtocolElement 

H 

See  Note. 

22 


Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 


Table  1 1  -  P2  BodyParts  (continued) 


Elements 

Class 

Restrictions  and  Comments 

TTX 

numberOfPages 

X 

telexCompat  ible 

X 

PI .TeletexNonBasicParams 

X 

SEQUENCE 

M 

T61String 

H 

See  Note. 

PI .TeletexNonBasicParams 

gr aphicChar act er Sets 

X 

controlCharacterSets 

X 

pageFormats 

X 

miscTerminalCapabilities 

X 

pr ivateUse 

X 

Videotex 

SET 

For  further  study  by  CCITT. 

VideotexString 

M 

NationallyDef ined 

ANY 

M 

Encrypted 

SET 

For  further  study  by  CCITT. 

BIT  STRING 

M 

ForwardedlPMessage 

delivery 

H 

Deliverylnformation 

H 

IM-UAPDU 

M 

Del i veryinf ormat  ion 

FX .  v^oncent  lype 

XT 

n 

originator 

M 

original 

M 

PI .Priority 

G 

DeliveryFlags 

M 

otherRecipients 

H 

thisRecipient 

M 

intendedRecipient 

H 

converted 

X 

submission 

M 
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Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 

Table  1 1  -  P2  BodyParts  (concluded) 


Elements  Class  Restrictions  and  Comments 


SFD 

SFD . Document  M 
TIFl 

T73  Dociunent  M 
T73.ProtocolElement  H  See  note. 


Note:     This  element  is  not  an  addition  to  the  definition  of  the  BodyPart. 
It  is  described  here  to  show  that  the  SEQUENCE  may  contain  zero 
elements.  A  Problem  Report  has  been  submitted  to  the  CCITT  to 
clarify  whether  this  is  permissible.  The  NIST/OSI  Workshop 
will  adopt  the  CCITT  decision. 


5.4      Reliable  Transfer  Server  (RTS) 


5.4.1       implementation  Strategy 

Based  on  X.410  Clause  3  and  X.411  Clause  3.5. 


5.4.2       RTS  Option  Selection 

The  nnaxinnum  number  of  simultaneous  associations  is  not  limited  in  this  profile;  if  the  capacity  of  a 
system  is  exceeded,  it  should  not  initiate  or  accept  additional  associations. 

Associations  are  established  by  the  MTA  which  has  messages  to  transfer. 

Associations  are  released  when  they  are  not  needed.  Associations  may  also  be  ended  prematurely  due 
to  internal  problems  of  the  RTS. 

For  both  monologue  and  two  way  alternate  associations,  the  initiator  keeps  the  initial  turn. 

When  establishing  an  RTS  association,  the  following  rules  apply  to  the  use  of  parameters  in  addition  to 
those  in  X.410  Clause  3.2.1: 

a)  Dialogue  mode:  Monologue  must  be  supported  for  this  profile;  two-way  alternate  is  used  only 
if  both  partners  agree. 

b)  Initial  turn:  Kept  by  the  initiator  of  the  association. 

The  'priority-mechanism'  and  the  'transfer-time  limit'  are  regarded  as  local  matters. 


24 


Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 

5.4.3       RTS  Protocol  Options  and  Clarifications 

Realization  of  tlie  RTS  protocol  is  subject  to  the  following  rules  in  addition  to  those  specified  in  X.410 
Clause  4: 

a)  One  RTS  association  corresponds  to  one  or  more  consecutive  session  connections  (not 
concurrent  ones).  The  first  is  opened  with  ConnectionData  of  type  OPEN,  and  subsequent  ones 
are  opened  with  type  RECOVER. 

b)  Recovery  of  a  Session  connection  is  only  by  RTS  initiator. 

c)  Checkpoint  size: 

1)  Checkpointing  and  No  Checkpointing  should  be  supported.  Whenever  possible, 
checkpointing  should  be  used. 

2)  The  minimum  checkpointSize  is  1  (that  is,  1024  octets). 

d)  Window  size: 

1)  Minimal  value  of  1  (if  checkpointing  is  supported). 

2)  WindowSize  =  1  means:  After  an  S-SYNCH-MINOR  request  is  sent,  wait  until  the 
confirmation  is  received  before  issuing  an  S-DATA,  S-SYNCH-MINOR,  or 
S-ACTIVITY-END  request. 

e)  APDUs  should  not  be  blocked  into  one  activity. 

f)  Only  one  SSDU  shall  be  transferred: 

1 )  Between  two  adjacent  minor  synch  points. 

2)  Between  minor  synch  points  and  adjacent  S-ACTIVITY-START  and  S-ACTIVITY-END 
requests. 

3)  Between  S-ACTIVITY-START  and  S-ACTIVITY-END  without  checkpoints. 

g)  A  monologue  association  is  defined  as  follows: 

1)  The  RTS  user  responsible  for  establishing  the  association  is  called  the  initiator. 

2)  The  initiator  keeps  the  initial  turn. 

3)  APDUs  are  transferred  in  the  direction  of  the  initiator  to  the  recipient  only. 

4)  There  shall  be  no  token  passing. 

5)  Only  the  initiator  can  effect  an  orderly  release  of  the  association. 
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h)  A  two-way  alternate  association  is  as  described  in  X.410. 

i)  In  the  UserData  parameter  of  the  S-U-ABORT,  the  ReflectedParameter  will  not  be  used  in  the 
Abortlnformation  element. 

j)  When  the  S-ACTIVITV-RESUME  is  used  to  resume  an  activity  in  the  same  session  connection 
as  the  one  in  which  it  started,  this  must  happen  immediately  after  the  activity  has  been 
interrupted  (i.e.,  no  intervening  activity  can  occur).  Otherwise,  X.410  Clause  4.3  paragraph  1  may 
be  violated. 

k)  When  S-ACTIVIPf-RESUME  is  used  to  resume  an  activity  started  in  another  session 
connection,  the  following  conditions  must  be  met: 

1 )  The  current  session  connection  is  of  type  "recover." 

2)  The  value  of  OldSessionConnectionldentifier  in  S-ACTIVITY-RESUME  must  match  the 
value  of  the  SessionConnectionldentifier  parameter  used  in  the  S-CONNECT  of  the  prior 
session  connection.  This  value  is  also  identical  to  the  SessionConnectionldentifier  in  the 
ConnectionData  (in  PConnect,  in  SS-UserData)  for  the  current  session  connection. 

3)  This  must  occur  as  the  first  activity  of  the  next  session  connection  for  the  same 
RTS-association.  It  must  be  the  first,  otherwise  X.410  Clause  4.5.1  point  1  is  violated. 

WdTE  -  It  is  in  the  same  RTS-ASSOCIATiON  because  the  use  of  S-ACTIVITY-RESUME  only  makes  sense 
within  the  scope  of  one  RTS  association. 

I)  If  the  transfer  of  an  APDU  is  interrupted  before  the  confirmation  of  the  first  checkpoint,  the 
value  of  the  SynchronizationPointSerialNumber  in  S-ACTIVITY-RESUME  should  be  zero,  and  the 
S-ACTIVITY-RESUME  must  be  immediately  followed  by  an  S-ACTIVITY-DISCARD. 

m)  In  S-TOKEN-PLEASE,  the  UserData  parameter  shall  contain  an  integer  conforming  to  X.409 
which  conveys  the  priority. 

n)  The  receiving  RTS  can  use  the  value  of  the  Reason  parameter  in  the 
S-U-EXCEPTION-REPORT  to  suggest  to  the  sending  RTS  that  it  should  either  interrupt  or 
discard  the  current  activity.  S-U-Exception  Reports  are  handled  as  stated  in  Version  5  of  the 
Implementors  Guide  pages  12-13,  paragraph  E-33. 

o)  In  the  case  of  S-P-ABORT,  the  current  activity  (if  any)  is  regarded  as  interrupted,  rather  than 
discarded. 

p)  Table  12  illustrates  the  legal  negotiation  possibilities  allowed  by  X.410  Clause  4.2.1  regarding 
checkpoint  size  and  window  size. 

q)  These  agreements  include  the  provisions  of  Version  6  of  the  Implementors  Guide  identical  in 
all  respects  to  Version  5,  except  that  the  following  points  have  been  added  to  clause  3.5: 

1)  for  section  4.4.1  of  X.410;  "If  the  receiving  RTS  receives  an  S-ACTIVITY-DISCARD 
indication  primitive  and  has  already  issued  a  TRANSFER  indication  primitive,  it  aborts 
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the  connection  (S-U-ABORT  request)  with  the  'transfer  completed'  version  code." 

2)  for  section  4.6.2  of  X.410  "The  'transfer  completed  (7)'  abort  reason  is  used  to 
indicate  to  the  sending  RTS  that  the  receiving  RTS  could  not  discard  the  activity 
because  it  has  already  completed  the  transfer  (issued  a  TRANSFER  indication  primitive)." 
Transfer  completed  (7)  is  also  added  to  the  table  of  abort  reasons  in  this  clause. 


Table  12  -  Checkpoint  Window  Size  of  IP 


acceptor  answer 

CS  =  0 
(or  unspecified) 
WS  unspecified 

CS  =  m 
WS  =  j 
(or  unspecified) 

CS  =  n 
WS  =  j 
(or  unspecified) 

initiator 
proposal 

CS  =  0 
(or  unspecified) 

WS  =  i 
(or  unspecified) 

legal 

legal 

legal 

CS  =  k 
WS  =  i 
(or  unspecified) 

legal 

legal 

not  allowed 

Legend 

CS:    means  CheckpointSize 
WS:    means  WindowSize 

i,  j,  k,  m,  and  n:     are  integer  values  with  the  following  relations: 
0  S  m  5  k  <  n     (values  assigned  to  CS) 
0  <  j  ^  i           (values  assigned  to  WS) 

For  unspecified  parameters,  the  default  applies.  In  this  case,  the 
numeric  relations  apply,  that  is,  the  default  values  substitutefor 
the  unspecified  integer. 

5.4.4       RTS  Protocol  Limitations 

The  RTS  Protocol  Limitations  for  this  profile  are  listed  in  table  13. 
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Table  13  -  RTS  Protocol  Elements 


Element 

Class 

Restriction 



PConnect 

M 

DataTrans£erSyntax 

n. 

value  —  u. 

pUserData 

M 

checkpointSize 

H 

windows ize 

H 

dialogueMode 

H 

Conne  c  t  i  onDa  t  a 

M 

applicationProtocol 

6 

Value  =  1. 

H 

Value  =  8883. 

Connect ionDat a 

open 

G 

'  recover 

G 

open 

!       RTS  user  data 

G 

recover 

Ses  s  i  onConnec t  ionldentifier 

G 

RTS  user  data 

mTAName 

G 

Maximum  length  32  characters 

graphic  subset  of  IA5  only. 

password 

G 

Maximum  length  64  octets 

graphic  subset  of  IA5  only. 

<  null  RTS  User  Data  > 

G 

Generated  if  other  validation 

methods  are  used. 

SessionConnect ionldentifier 

CallingSSUserReference 

M 

Maximum  length  64  octets  including 

CominonRe  f  e  r  enc  e 

M 

AdditionalRef erencelnformation  H 

Maximum  length  4  octets  including 

encoding  =  2  octets  of  T.61. 

PAccept 

G 

DataTransfer Syntax 

M 

Value  =  0. 

pUserData 

M 

checkpointSize 

H 

windowSize 

H 

Connect ionData 

M 
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Table  13  -  RTS  Protocol  Elements  (concluded) 


Element 

Class 

Restriction 

PRef use 

/-< 

RefuseReason 

M 

SS  User  Data 

G 

See  Note 

(in  S -TOKEN-PLEASE) 

Abort Information 

G 

(in  S-U- ABORT) 

AbortReason 

H 

ref lectedParameter 

X 

Restricted  to  8  bits. 

End  of  Definitions 

Note  -  Generated  if  supplied  by  the  RTS 
priority  in  the  TURN-PLEASE  primitive, 
SS-User-Data  in  S-TOKEN-PLEASE. 

-user.  The  RTS  use  may  specify  a 
and  if  so,  it  is  carried  as  the 

5.5      Use  of  Session  Services 

The  session  requirements  and  use  of  session  are  covered  in  part  5  of  tliis  document. 


5.6      Data  Transfer  Syntax 

This  clause  defines  Presentation  Transfer  Syntax  and  notation  rules  applicable  to  these  agreements. 
Implementations  must  conform  EXACTLY  as  specified  in  X.409  with  no  further  restrictions.  Annex  C 
defines  rendition  of  IA5  Text  and  T61  characters. 


6     PRMD  to  ADMD  and  ADMD  to  ADMD 


6.1  Introduction 

This  clause  defines  the  implementation  agreements  that  apply  to  the  interface  between  two  management 
domains  when  at  least  one  is  an  ADMD.  A  message  arriving  at  an  ADMD  has  either  no  recipient  within 
that  domain  or  one  or  more  recipients  within  that  domain.  In  the  former  case,  the  ADMD  serves  as  a 
relay  between  two  or  more  domains  and  the  actions  required  of  that  ADMD  are  independent  of  the 
nature  (PRMD  or  ADMD)  of  the  domains.  In  the  latter  case,  the  ADMD  is  responsible  for  delivering 
messages  to  the  proper  recipient(s)  within  its  jurisdiction,  and  may  also  be  responsible  for  relaying  the 
message. 

Given  the  two  roles  for  an  ADMD,  this  clause  describes  two  distinct  sets  of  functional  requirements  for 
an  ADMD.  The  first  is  the  relaying  requirement  that  is  needed  to  provide  PRMD  and  other  ADMD 
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interworking.  The  second  is  analogous  to  the  PRMD's  support  to  its  customers  through  the  integrated 
UAs.  These  are  distinct  functional  differences.  The  services  provided  to  the  UAs  of  an  ADMD  are 
independent  of  the  requirennent  that  an  ADMD  provide  a  function  for  interworking  with  any  type  of 
Management  Domain  (MD).  Figure  5  illustrates  the  two  roles  played  by  an  ADMD. 

This  clause  is  presented  in  the  form  of  deviations  from  the  agreements  applicable  to  PRMD-to-PRMD 
(sec.  5).  Unless  explicitly  noted  in  the  remainder  of  this  clause,  all  of  the  specifications  for  PRMD  to 
PRMD  apply  to  PRMD  to  ADMD  and  ADMD  to  ADMD. 


PRMD  or  ADMD 

IPM  -  UA 

<  

MTA 

 P2— 

 Pi- 
ca) 


— > 
— > 

ADMD 

IPM  -  UA 

MTA 

PRMD  or 

ADMD 

IPM  - 

UA 

< — 

MTA 

PRMD  or  ADMD 

-> 

IPM  -  UA 

MTA 

PI 


PI 


(b) 


Figure  5  -  An  ADMD  May  (b)  or  May  Not  (a)  Serve  as  a  Relay. 
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6.2      Additional  ADMD  Functionality 

The  following  defines  the  additional  ADMD  specific  functionality  required  over  and  above  that  specified  in 
the  PRMD  clause. 

6.2.1  Relay  Responsibilities  of  an  ADMD 

ADMDs  will  relay  all  content  types  (not  just  P2)  unchanged  in  the  absence  of  a  request  for  conversion. 

6.2.2  PI  Protocol  Classification  Changes 

Table  14  describes  the  changes  to  the  PRMD  P1  Protocol  classifications  required  for  a  delivering 
Administration  domain  (with  respect  to  the  original  message;  this  means  the  domain  which  originates  the 
delivery  reports). 


Table  14  -  Pi  Protocol  Classification  Changes  for  a  Delivering  ADMD 


Protocol  Elements 

Class 

Deliveredlnfo 
typeOfUA 

H 

ReportedRecipientlnfo 

Supplementarylnf ormat  ion 

H           See  Note  1. 

GlobalDomainldentif ier 
PrivateDomainldentif ier 

H 

For  relaying  Administration  domains,  the  classifications  are  all  "X" 

For  originating  Administration  domains,  these  are  all  "NOT  APPLICABLE." 

Notes 

1    Domains  providing  access  to  TELEX/TELETEX  recipients,  whether 
directly  or  indirectly  as  a  result  of  bilateral  agreements 
between  domains,  must  ensure  that  this  information,  when 
present,  is  accessible  by  the  recipient  of  the  delivery  report. 

6.2.3       0/R  Names 

0/R  Names  shall  consist  of: 

a)  CountryName, 

b)  AdministrationDomainName. 
as  well  as  one  of  the  following: 
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a) 

PrivateDomainName, 

b) 

PersonalName, 

c) 

OrganizationName, 

d) 

OrganizationalUnit, 

e) 

UniqueUAIdentifier, 

f) 

X1 21  Address. 

and  permits  the  optional  inclusion  of  a 
a)  DomainDefinedAttributeList. 

NOTE  -  The  destination  PrivateDomainName  or  OrganizationName  must  be  present  if  destined  for  a 
I         PRMD.  The  ADMD  relaying  the  message  to  that  destination  PRMD  requires  this  element. 

6.2.4       PI  ADMD  Name 

Managennent  Domains  (MDs)  must  specify  in  the  ADMD  name  field  of  the  0/R  Name 
StandardAttributeLlst  in  P1 ,  the  name  of  the  Administration  domain: 

a)  to  which  the  message  is  being  sent  (in  recipient  names) 

b)  from  which  the  message  originated  (in  the  originator  name). 

6.3      Interworking  with  Integrated  UAs 

If  the  message  originates  at  a  UA  owned  by  an  ADMD,  or  is  delivered  to  such  a  UA,  the  0/R  Name 
follows  the  same  Form  1  Variant  1  constraints  as  the  base  specifications;  except  that  the  ADMD  name  is 
the  name  of  the  ADMD  that  owns  the  UA  and  instead  of  supplying  a  PRMD  Name,  one  (or  more)  of  the 
following  must  be  provided: 

a)  OrganizationName, 

t       b)  OrganizationalUnit, 

c)  PersonalName. 
and  may  optionally  include  a 

a)  DomainDefinedAttributeList. 
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6.4.1       TTC  Profile 

There  are  no  outstanding  issues  regarding  interworking  between  TTC-conformant  systems  and 
NIST-conformant  systems  with  the  exception  of  the  number  of  recipients  and  the  supported  IVIPDU  sizes. 
The  Extensionldentifier  field  may  contain  a  maximum  value  of  32K-1 ;  however,  according  to  the  current 
TTC  profile,  if  a  message  with  more  than  256  recipients  is  received,  some  TTC-conformant  domain  may 
generate  a  nondelivery  notification.  This  also  applies  to  the  ReportedRecipientlnfo  in  a  delivery  report. 
Further,  a  TTC  MTA  is  required  to  handle  an  MPDU  size  of  at  least  32KB.  The  NIST  required  MPDU  size 
is  2MB  as  covered  in  clause  5.3.3.  Other  differences  are  shown  in  annex  E.  TTC  is  currently  based  on 
Version  4  of  the  Implementor's  Guide. 


6.4.2       CEPT  Profile 

See  annex  E. 


6.5      Connection  of  PRMDs  to  Multiple  ADMDs 

Given  that  Management  Domain  names  (both  PRMD  and  ADMD)  shall  be  unique  within  the  United 
States,  then  when  an  ADMD  is  presented  a  message  for  transfer  from  a  PRMD,  it  will  accept  0/R  Names 
(both  originator  and  recipient)  which  have  an  AdministrationDomainName  field  value  different  than  the 
Administration's  name.  "Accept"  implies  the  attempt  to  route/deliver  the  message  shall  be  made,  as 
appropriate,  based  upon  the  knowledge  that  MD  names  are  unique. 

Whether  this  functionality  is  required  by  an  Administration  for  conformance  to  this  agreement  is  for 
further  study. 

If  a  PRMD  is  connected  to  two  or  more  ADMDs  which  are  not  effectively  connected  (either  directly  or  via 
a  third  ADMD),  full  X.400  functionality  shall  not  be  available.  Problems  occur  especially  in  the  areas  of: 

a)  Naming, 

b)  Routing, 

c)  Replying. 

It  should  be  noted  that  a  single  PRMD  that  is  connected  to  more  than  one  ADMD  can  be  represented  by 
more  than  one  combination  of  country-name,  ADMD-name,  and  PRMD  name.  For  example,  it  may  occur 
that  the  PRMD-name  for  a  particular  PRMD  may  take  different  values,  depending  on  the  ADMD-name. 
Implementors  should  be  aware  of  the  consequences  of  these  possibilities  on  routing. 
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6.6  Connection  of  an  ADMD  to  a  Routing  PRMD 

It  is  possible  for  a  collection  of  interconnected  private  domains  to  establish  one  domain  as  the  "gateway" 
to  an  ADMD,  and  hence  to  the  world. 

If  an  ADMD  is  connected  to  such  a  gateway  PRMD,  the  individual  private  domains  shall  be  registered 
with  the  Administration.  Administrations  need  not  support  such  connections. 

Note  also  that  upon  receipt  by  the  ADMD  of  a  message  originating  somewhere  within  the  PRMD 
collection,  that  the  Trace! nformation  may  contain  more  than  one  element. 

The  X.400  Recommendations  specify  that  an  ADMD  should  not  attempt  to  relay  a  message  destined  for 
another  ADMD  through  a  PRMD,  thus  an  ADMD  should  ensure  that  messages  destined  for  another 
ADMD  are  not  relayed  through  a  PRMD.  It  should  be  noted,  however,  that  a  relaying  PRMD  will  relay  any 
such  message  it  receives. 

6.7  Management  Domain  Names 

All  Management  Domain  Names  (both  Private  and  Administration)  shall  be  unique  within  the  U.S. 
A  central  naming  authority  shall  be  established  to  register  domain  names. 


6.8      Envelope  Validation  Errors 

For  validation  errors,  a  non-delivery  notice  shall  be  generated  (if  possible)  with  reason  code  of 
'unableToTransfer'  and  diagnostic  code  of  'invalidParameters'  (unless  specified  otherwise). 

ADMDs  will  validate  P1  Envelopes  in  the  following  areas: 

a)  The  X.409  syntax  of  all  elements  should  be  checked. 

b)  The  pragmatic  constraint  limits  (lengths  of  fields  and  number  of  occurrences  of  fields)  should 
be  checked. 

c)  Semantic  validation  of  the  following  elements  should  be  done: 

1)  originator  0/R  Name, 
j  2)  recipient  0/R  Name  in  the  Recipientlnfo, 

3)  Priority. 

d)  Only  recipient  Names  with  the  responsibility  flag  set  should  be  validated.  The  validation  of 
0/R  names  is  defined  in  8.3.3;  the  validation  of  priority  is  defined  in  8.3.7.1. 

e)  MPDU  Identifier  Validation 
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1)  Validation  of  the  GlobalDomainldentifier  component  of  tlie  MPDU  Identifier  is 
perfornned  upon  reception  of  a  message  (i.e.,  as  a  result  of  a  TRANSFER. Indication). 

2)  The  country  name  should  be  known  to  the  validating  domain,  and  depending  on  the 
country  name,  validation  of  the  ADMD  name  may  also  be  possible. 

3)  Additional  validation  of  the  GlobalDomainldentifier  is  performed  against  the 
corresponding  first  entry  in  the  Tracelnformation.  If  inconsistencies  are  found  during  the 
comparison,  a  non-delivery  notice  with  the  above  defined  reason  and  diagnostic  codes 
is  generated. 

4)  A  request  will  be  generated  to  the  CCITT  for  a  more  meaningful  diagnostic  code 
(such  as  'InconsistentMPDUIdentifier'). 


6.9      Quality  of  Service 


6.9.1       Domain  Availability 


6.9.1.1         ADMD  Availability 

The  goal  is  to  provide  24  hour  per  day  availability.  Note  that  there  will  be  periods  of  time  when  an  ADMD 
may  be  unavailable  due  to  maintenance  windows  in  its  supporting  networl<  or  in  an  MTA  within  the 
domain. 


6.9.1.2        PRMD  Availability 

Although  the  goal  of  PRMD  availability  is  also  24  hours  per  day,  business  reasons  are  lil<ely  to  dictate 
some  different  level  of  availability.  ADMDs  shall  require  a  profile  from  the  PRMD  that  indicates  its 
schedule  of  regular  availability  to  the  ADMD. 


6.9.2       Delivery  Times 

In  the  absence  of  standardized  quality  of  service  parameters,  the  following  are  agreed  to.  When 
standardized  parameters  from  CCITT  Study  Group  I  become  available,  they  shall  be  adopted. 

a)  In  table  15  the  delivery  time  targets  are  established. 

b)  The  interval (s)  between  retries  and  the  number  of  retry  attempts  that  an  ADMD  uses  in 
attempting  delivery  to  a  PRMD  or  integrated  UA,  will  be  locally  determined  domain  parameters. 
However,  the  total  elapsed  times  after  which  delivery  attempts  will  be  stopped  are  shown  in  table 
16.  This  implies  that,  after  these  times,  a  Non-Delivery  Notice  will  be  generated. 

c)  An  Administration  shall  continue  to  attempt  delivery  until  the  forced  nondelivery  time,  even  if 
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the  recipient  domain  has  scheduled  an  unavailability  window. 


Table  15  -  Delivery  Time  Targets 


Delivery  Class 

95%  Delivered  Before 

Urgent 
Normal 
Non-Urgent 

3/4  hour 
4  hours 
24  hours 

Table  16  -  Forced  Nondelivery  Times 


Delivery  Class 

NonDelivery  Forced  After 

Urgent 
Normal 
Non-Urgent 

4  hours 
24  hours 
36  hours 

NOTE  -  Both  tables  apply  to  the  period  between  acceptance  by  the  originating  MTA  in  the  originating 
Administration  domain  to  the  time  of  delivery  in  the  destination  Administration  domain.  Transit  time  within 
PRMDs  is  NOT  included  in  the  above  times. 


6.10    Billing  Information 

All  aspects  relating  to  billing,  charging,  tariffs,  settlement,  and  in  particular  to  the  use  of  the 
billinglnformation  field  in  the  delivery  report,  is  subject  to  bilateral  agreement,  and  shall  not  be  addressed 
in  these  implementation  agreements. 

No  ADMD  shall  require  a  PRMD  to  supply  or  process  billing  information. 


6.11  Transparency 

No  P1  extensions,  other  than  the  MOTIS  extensions  are  to  be  allowed  (Reference  A/3211).  Should  an 
ADMD  receive  a  message  containing  PI  extensions,  it  shall  generate  a  non-delivery  notice  (if  possible) 
with  reason  code  of  unableToTransfer  and  diagnostic  code  of  invalid  Parameters. 

If  MOTIS  elements  are  present,  a  relaying  MTA  can  optionally: 

a)  Relay  the  message.  If  the  MTA  does  relay,  it  must  not  drop  any  of  the  protocol  elements. 

b)  Non-Deliver  the  message. 
A  receiving  MTA  can  optionally: 

a)  Deliver  the  message 

b)  Non-Deliver  the  message. 
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The  CCITT  has  been  requested  to  establish  a  more  meaningful  diagnostic  code  (such  as  protocolError) 
for  this  occurrence.  Such  a  code  has  now  been  provided  in  the  Implementors  Guide. 

P2  extensions  shall  be  relayed  transparently  by  ADMDs. 


6.12    RTS  Password  Management 

RTS  password  management  shall  be  a  local  matter.  This  includes: 

a)  password  length 

b)  frequency  of  changes 

c)  exchange  of  passwords  with  communicating  partners 

d)  loading  passwords  ( i.e.,  the  timing  of  password  changes  with  respect  to  active 
associations). 


6.13     For  Further  Study 

Issues  requiring  further  study  are: 

a)  Intra-Domain  Routing 

b)  Multi-Vendor  Domains 


7     Inter  and  Intra  PRMD  Connections 


7.1  Introduction 

This  clause  is  limited  in  scope  to  issues  arising  from  the  indirect  connection  of  a  PRMD  to  another 
PRMD  or  to  an  ADMD,  and  to  the  interconnection  of  MTAs  to  form  inter-PRMD  connections.  Indirect 
means  that  the  connection  is  made  via  a  relaying  PRMD.  The  X.400  Recommendations  describe  the  way 
that  a  PRMD  connects  to  a  ADMD  and  the  way  that  an  ADMD  connects  to  another  ADMD.  The 
Recommendations  do  not,  however,  describe  the  way  that  a  PRMD  connects  indirectly  to  an  ADMD  or 
another  PRMD,  nor  do  they  describe  the  way  that  MTAs  are  connected  within  a  PRMD.  These 
configurations  (shown  in  figures  6  and  7)  are  useful,  for  example,  in  connecting  equipment  from  different 
vendors  at  a  single  customer  site. 

The  P1  protocol  and  its  related  services  for  both  inter  and  intra  PRMD  connections  are  addressed  in  this 
clause.  In  addition,  a  method  for  routing  within  a  PRMD  is  given.  It  is  recognized  that  uniform  methods 
for  Administration,  maintenance,  and  quality  of  service  should  be  developed  for  such  configurations,  and 
this  work  is  for  further  study. 
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This  clause  describes  the  minimum  that  must  be  provided  in  order  to  implement  a  relaying  PRMD  and  a 
MTA  within  a  PRMD. 

This  clause  is  presented  in  the  form  of  deviations  from  agreements  applicable  to  PRMD  to  PRMD 
connection  (sec.  5).  That  is,  unless  specifically  noted  in  the  remainder  of  this  clause,  the  agreements  in 
clause  5  apply  to  both  relaying  PRMDs  and  MTAs  within  a  PRMD. 

It  should  be  noted  that  the  comments  regarding  ORNames  in  clause  6.5  also  apply  to  this  clause. 


7.2      The  Relaying  PRMD 

A  PRMD  that  has  the  capability  of  relaying  messages  to  another  PRMD  is  called  a  relaying  PRMD.  A 
PRMD  implementation  need  not  claim  to  be  a  relaying  PRMD.  A  PRMD  implementation  which  does  claim 
to  be  a  relaying  PRMD  must  follow  the  implementation  agreements  in  this  clause. 


7.2.1       Relay  Responsibilities  of  a  PRMD 

The  responsibilities  of  a  relaying  PRMD  are  the  same  as  those  of  an  ADMD  (as  specified  in  sees.  6.8  and 
6.2.1).  In  addition,  the  PRMD  will  simply  deliver  messages  routed  to  it  from  an  ADMD,  even  if  this  results 
in  routing  a  message  from  the  ADMD  to  the  PRMD  to  another  ADMD. 


7.2.2       Interaction  with  an  ADMD 

In  order  for  an  ADMD  to  route  a  message  to  ADMD  A  via  ADMD  B,  it  must  know  that  A  is  reachable 
through  B.  Similarly,  in  order  for  any  MD  to  route  a  message  to  PRMD  A  via  a  relaying  PRMD  B,  it  must 
know  that  A  is  reachable  through  B  (see  figure  8). 


ADMD 


PRMD  A 

PRMD  B 

PRMD  C 

Relay 


Figure  6  -  Relaying  PRMD. 

ins  fiytti-.: 
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PRMD 


MTA  A 


MTA  D 


MTA  B 


Figure  7  -  Intra  PRMD  connections. 


NOTES 


1  Clause  6.6  specifies  that  ADMDs  are  not  required  to  connect  to  a  relaying  PRMD,  but  they  are  not 
precluded  from  doing  so. 

2  Tracelnformation  may  have  more  than  one  sequence  on  submission  of  a  message  by  a  relaying  PRMD 
to  an  ADMD. 


MD  D 

"T~ 


relay 

MD    C  with 
a  message 
for  A 


relay 
MD  B 

MD  A 

Figure  8  -  MD  C  must  know  of  A  to  route  the  message. 


7.3      Intra  PRMD  Connections 


A  PRMD  is  composed  of  MTAs  which  cooperate  to  perform  the  functions  expected  of  a  domain.  An  MTA 
implementation  need  not  claim  to  follow  the  implementation  agreements  of  this  clause. 


7.3.1        Relay  Responsibilities  of  an  MTA 

The  relaying  responsibilities  of  an  MTA  are  the  same  as  those  of  an  ADMD  (as  specified  in  6.8  and  6.2.1) 
with  one  exception:  loop  suppression  within  the  domain  is  done  using  the  MOTIS  InternalTracelnfo 
protocol  element.  The  MTA  must  validate  the  InternalTracelnfo  (see  8.3.5  for  details  on  validation).  In 
addition,  the  PRMD  will  simply  deliver  messages  routed  to  it  from  an  ADMD,  even  if  this  results  in  routing 
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a  message  from  the  ADMD  to  the  PRMD  to  another  ADMD  (please  see  6.6). 


7.3.2        Loop  Suppression  within  a  PRMD 

The  only  mechanism  defined  in  the  X.400  Recommendations  for  suppressing  loops  is  Tracelnformation, 
which  is  added  on  a  per  domain  basis  to  detect  and  suppress  loops  among  domains.  Loops  among 
MTAs  within  a  domain  need  to  be  detected  and  suppressed.  This  implies  that  each  MTA  must  add  trace 
information  that  is  meaningful  within  the  domain.  The  MOTIS  solution  of  adding  InternalTracelnfo  to  the 
P1  Envelope  of  a  message  was  adopted.  The  definition  of  InternalTracelnfo  is  given  in  figure  9.  The 
InternalTracelnfo  is  added  by  each  MTA  within  a  PRMD  to  handle  a  message,  and  it  is  examined  in  the 
same  way  as  Tracelnformation  to  detect  and  suppress  loops. 


InternalTracelnfo 

::=  [APPLICATION  30]   IMPLICIT  SEQUENCE  OF  SEQUENCE  { 

MTAName , 

MTASuppliedlnfo  } 

MTAName 

::=  PrintableStr ing 

Figure  9  -  Definition  of  InternalTracelnfo. 


If  the  MTAName  and  password  of  X.41 1  are  used  for  validation,  then  it  is  recommended  that  the 
MTAName  used  for  validation  also  be  used  in  the  InternalTracelnfo.  However,  there  is  a  complication:  in 
X.411,  MTAName  is  an  lASString,  and  the  MTAname  defined  by  MOTIS  is  a  PrintableString.  Efforts  will  be 
made  to  change  the  MOTIS  definition  from  PrintableString  to  lASString. 

Three  actions  are  defined  in  MTASuppliedlnfo:  relayed,  rerouted,  and  recipientReassignment  as  shown  in 
figure  10.  The  recipientReassignment  action  is  not  supported  in  these  agreements.  The  ability  to 
generate  it  is  not  required,  and  if  it  is  present  on  an  incoming  message,  the  action  field  will  be  ignored. 


MTASuppliedlnfo 

: : =  SET  { 

arrival 

[0]   IMPLICIT  Time, 

deferred 

[1]   IMPLICIT  Time  OPTIONAL, 

action 

[2]   IMPLICIT  INTEGER  { 

relayed 

(0), 

rerouted 

(1), 

recipientReassignment 

(2)  } 

previous 

MTAName  OPTIONAL  ) 

Figure  10  -  Defined  Actions  in  MTASuppliedlnfo. 


7.3.3        Routing  Within  a  PRMD 

Routing  within  a  PRMD  is  complicated  by  the  lack  of  a  directory  standard.  In  particular,  it  constrains 
intra-domain  routing  decisions  to  be  based  on  some  combination  of  the  intra-domain  attributes  of  the 
0/R  Name,  Organization  Name  Organizational  Units,  and  Personal  Name.  In  order  to  enhance 
interworking  and  to  reduce  the  difficulty  of  configuring  intra-domain  connections,  it  is  useful  to  restrict 
the  ways  in  which  these  may  be  used  in  making  routing  decisions. 
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However,  it  is  recognized  tliat  vendors  may  wish  to  provide  MTAs  with  varying  degrees  of  routing 
capability  within  a  PRMD  as  a  temporary  expedient  until  appropriate  standards  for  automated 
construction  of  directories  and  routing  tables  are  available.  This  clause  assigns  class  numbers  to  certain 
levels  of  routing  capability  and  discusses  the  consequences  of  using  MTAs  which  fall  into  each  class. 
The  classification  scheme  will  allow  some  diversity  in  allocating  0/R  Name  space  and  in  configuring 
intra-domain  routes. 

When  other  methods  are  recommended  by  standards  bodies,  the  classification  scheme  described  here 
will  become  obsolete.  Large-scale,  multi-vendor  PRMDs  may  not  be  practical  in  the  absence  of 
standardized  methods. 


7.3.3.1         Class  Designations 

When  it  is  clear  that  a  message  is  to  be  delivered  within  a  domain,  the  Country  Name,  ADIVID  Name,  and 
PRMD  Name  have  already  served  their  purpose  in  determining  the  next  MTA  in  the  route  to  the  recipient. 
The  remaining  fields  that  might  be  used  on  mal<ing  routing  decisions  within  the  PRMD  are  the 
Organization  Name,  Organizational  Units,  and  Personal  Name. 

MTAs  are  classified  by  their  ability  to  discriminate  between  0/R  names  when  making  routing  decisions 
within  a  PRMD.  Conformant  MTAs  will  be  classified  as  shown  in  table  17. 


Table  17  -  Conformant  MTA  Classifications 


Class  1 

Class  2 

Class  3 

Organization  Name 

H 

H 

H 

SEQUENCE 

OF  Organizational  Unit 

X 

H 

H 

Personal 

Name 

X 

X 

H 

An  'H'  means  that  the  MTA  must  be  able  to  base  its  intra-domain  routing  decisions  on  the  given 
component  of  the  0/R  Name.  In  particular,  both  Class  2  and  Class  3  MTAs  must  be  able  to  discriminate 
on  all  the  members  in  a  supplied  sequence  of  OrganizationalUnits.  A  Class  3  MTA  must  be  able  to 
discriminate  on  all  of  the  elements  in  a  PersonalName. 

An  'X'  means  that  the  MTA  need  not  have  the  ability  to  discriminate  on  the  given  component. 

There  is  a  hierarchy  in  support  of  components.  The  ability  to  discriminate  on  a  given  component  does 
not  imply  the  requirement  to  do  so:  e.g.,  a  Class  3  MTA  is  not  required  to  have  tables  for  every 
PersonalName  in  the  domain.  Equally,  an  MTA  which  can  discriminate  on  OrganizationalUnits  to  make 
routing  decisions  need  not  always  use  the  full  sequence  in  an  0/R  Name  if  a  partial  sequence  provides 
enough  information. 

The  above  classifications  only  apply  to  routing  decisions  in  selecting  a  next  hop  within  a  domain.  All 
MTAs  are  entitled  to  examine  the  full  0/R  Name  when  identifying  their  own  directly  served  UAs. 

The  routing  table  of  a  Class  1  MTA  will  be  relatively  small,  because  intra-domain  routing  decisions  are 
based  solely  on  OrganizationName.  The  routing  table  of  a  Class  2  MTA  may  be  substantially  larger  and 
more  complex  because  of  its  ability  to  discriminate  on  OrganizationalUnits  as  well  as  OrganizationName 
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to  make  routing  decisions.  The  routing  table  of  a  Class  3  MTA  may  be  larger  still,  because  its  use  of  the 
components  of  PersonalName  in  addition  to  the  other  information. 


7.3.3.2        Specification  of  MTA  Classes 


If  an  MTA  implementation  claims  to  follow  the  implementation  agreements,  it  must  be  either  a  Class  1 , 
Class  2,  or  a  Class  3  MTA.  The  class  of  an  MTA  implementation  should  be  specified  so  that  PRMD 
administrators  can  choose  equipment  properly. 


7.3.3.3        Consequences  of  Using  Certain  Classes  of  MTAs 

Definition:  An  MTA  which  accepts  submission  requests  and  furnishes  delivery  indications  to  a  UA  is  said 
to  "directly  serve"  the  UA. 

The  presence  in  a  domain  of  an  MTA  acting  as  a  Class  1  or  Class  2  MTA  imposes  administrative 
restrictions  on  the  assignment  of  0/R  Names  to  UAs  and  in  the  configuration  of  routes  within  that 
domain. 


A  Class  1  MTA  may  directly  serve  UAs  from  several  OrganizationNames.  However,  if  a  Class  1  MTA 
directly  serves  a  UA  with  a  given  OrganizationName,  no  other  MTA  in  the  domain  may  directly  serve  a 
user  with  the  same  OrganizationName.  This  means  that  if  all  MTAs  in  a  domain  are  Class  1 ,  then  all  UAs 
with  a  given  OrganizationName  must  be  assigned  to  the  same  MTA. 

A  Class  2  MTA  may  directly  serve  UAs  from  any  combination  of  OrganizationName  and  sequence  of 
OrganizationalUnits.  However,  if  a  Class  2  MTA  directly  serves  a  UA  with  a  given  combination,  no  other 
MTA  in  the  domain  may  directly  serve  a  user  with  the  same  combination.  This  means  that  if  all  MTAs  in  a 
domain  are  Class  2,  then  all  UAs  with  a  given  OrganizationName  and  sequence  of  OrganizationalUnits 
must  be  assigned  to  the  same  MTA. 

A  domain  consisting  entirely  of  Class  3  MTAs  is  free  of  all  the  above  restrictions. 

If  Class  1  or  Class  2  MTAs  are  used  to  perform  relaying  within  a  PRMD  containing  MTAs  of  other 
classes,  care  must  be  exercised  in  determining  the  topology  of  the  domain  to  avoid  leaving  certain  UAs 
inacessible  from  certain  MTAs  within  the  domain.  The  example  below  shows  one  of  the  configurations 
that  should  be  avoided.  The  example  is  intended  to  stimulate  careful  examination  of  the  relationship 
between  network  and  organizational  topologies. 


MTA  A 
serving 
Organization  X 


MTA  B 
(Class  1) 


MTA  C 
serving 
Organization  X 


Figure  11  -  Example  of  a  Configuration  to  be  Avoided. 
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in  figure  11,  B  wlli  route  aii  messages  for  Organization  X  to  either  A  or  C  because  B  is  a  Class  1  MTA. 
The  administrator  who  created  this  configuration  probably  wanted  B  to  route  some  messages  for 
Organization  X  to  A,  and  some  to  0.  However,  B  does  not  have  the  capability  for  this  because  it  is  only 
a  Class  1  MTA.  The  configuration  in  figure  1 1  can  be  corrected  by  replacing  B  with  a  Class  2  or  Class  3 
MTA. 


7.3.4       Uniqueness  of  MPDUidentifiers  Within  a  PRMD 

When  generating  an  lASString  in  an  MPDUIdentifier,  each  MTA  In  a  domain  must  ensure  that  the  string  is 
unique  within  the  domain.  This  shall  be  done  by  providing  an  MTA  designator  with  a  length  of  12  octets 
which  Is  unique  within  the  domain,  to  be  concatenated  to  a  per  message  string  with  maximum  length  of 
20  octets. 

Two  pieces  of  information,  the  MTA  name  and  MTA  designator,  need  to  be  registered  within  a  PRMD  to 
guarantee  uniqueness.  This  registration  facility  need  not  be  automated.  If  the  MTA  name  Is  less  than  or 
equal  to  12  characters,  It  Is  recommended  that  It  also  be  used  as  the  MTA  designator. 


7.4      Service  Elements  and  Optional  User  Facilities 

A  PRMD  made  up  of  MTAs  which  support  varying  sets  of  service  elements  in  addition  to  those  required 
In  these  agreements  may  appear  to  provide  inconsistent  service  for  these  elements.  For  example.  If  one 
MTA  supports  deferred  delivery  and  another  MTA  does  not,  then  deferred  delivery  can  be  used  by  some, 
but  not  all,  users  In  the  PRMD.  Similarly,  if  one  MTA  supports  return  of  contents  and  another  does  not, 
then  a  user  outside  of  the  PRMD  will  receive  returned  contents  for  messages  sent  to  one  user,  but  not 
for  messages  sent  to  another  user.  Note  that  this  same  inconsistency  occurs  when  sending  to  two 
PRMDs  which  support  different  additional  optional  elements. 


7.5      X.400  Protocol  Definitions 

This  clause  describes  additions  and  modifications  to  clause  5.3  which  are  required  for  implementation  of 
a  relaying  PRMD  or  an  MTA  within  a  PRMD. 


7.5.1       Protocol  Classification 

The  classification  scheme  given  In  clause  5.3.1  applies  to  elements  passing  from  one  PRMD  to  another. 
For  both  relaying  PRMDs,  and  MTAs  in  a  PRMD,  the  same  classification  scheme  will  be  used,  but  within 
a  PRMD  the  classification  applies  to  elements  passing  from  one  MTA  to  another. 

In  addition  to  the  classifications  given  in  clause  5.3.1,  a  classification  of  Prohibited  has  been  used. 
PROHIBITED  =  P 

This  element  shall  not  be  used.  Presence  of  this  element  is  a  protocol  violation. 
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7.5.2       PI  Protocol  Elements 

Table  18  contains  protocol  elements  and  their  classes.  An  *  signifies  that  the  classification  of  the 
protocol  element  has  not  changed  from  table  8. 


Table  18  -  Pi  Protocol  Elements 


Element 

Class 

Restrictions  and  Comments 

UMPDUEn ve 1 ope 
MPDUIdentif ier 

M* 

This  field  needs  to  be  unique 
within  a  PRMD.     See  clause 
7.3.4  for  the  method  of 
ensuring  uniqueness. 

originator 

M* 

It  is  recommended  that  all 
components  of  the  originator's 
ORName  be  included  to  help  ensure 
that  reports  can  be  returned. 

Tracelnformation 

M* 

The  first  MTA  in  the  domain  to 
receive  the  message  adds  the 
Tracelnformation.  Subsequent 
MTAs  can  update  the 
Tracelnformation  in  the  event  of 
conversion  or  deferred  delivery. 
When  a  message  is  generated,  the 
originating  MTA  adds  the 
Tracelnformation. 

InternalTracelnfo 

M/P 

This  element  is  mandatory  for 
envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
Elements  are  always  added  to  the 
end  of  the  sequence.   (See  Note  1) 

InternalTracelnfo 
MTAName 

M 

MTANames  within  a  PRMD  must  be 
unique.  See  clause  7.3.4  for 
the  method  of  assuring  uniqueness 
Maximum  length  -  32  characters. 

MTASuppliedlnfo 

M 
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Table  18  -  PI  Protocol  Elements  (continued) 


Element 

Class 

Restrictions  and  Comments 

MTASuppl i  edinf o 
arrival 
deferred 

M 
X 

This  field  must  be  generated  by 
MTAs  which  perform  deferred 
delivery. 

action 

M 

See  clause  7.3.2  for 
restrictions  on  values  of  this 
field. 

previous 

X 

This  field  must  be  generated  by 
MTAs  which  perform  rerouting. 

DeliveryReportEnvelope 
Tracelnformation 

M* 

The  first  MTA  in  the  domain  to 
receive  the  report  adds  the 
Tracelnformation.  When  a  report 
is  generated,  the  originating  MTA 
adds  the  Tracelnformation. 

InternalTracelnfo 

DeliveryReportContent 

intermediate  InternalTracelnfo 

M/P 
P 

This  field  is  mandatory  for 
envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
(See  Note  1) 

If  it  were  possible  to  include 
this  field  in  the  delivery  report 
content,  an  audit  and  confirmed 
report  could  be  provided  to 
detect  problems  within  a  PRMD. 
Efforts  are  being  made  to  add 
this  field  to  the  MOTIS 
definition. 

Deliveredlnfo 
typeOFUA 

R* 

It  is  the  responsibility  of  the 
MTA  generating  the  report  to 
generate  this  element. 
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Table  18  -  PI  Protocol  Elements  (concluded) 


Element 


Class 


Restrictions  and  Coxtunents 


ProbeEnvelope 

Traceinf ormation 


InternalTracelnfo 


M*  The  first  MTA  in  the  domain  to 

receive  the  probe  adds  the 
Traceinf ormation.  When  a  probe 
is  generated,  the  originating  MTA 
adds  the  Traceinf ormation. 

M/P         This  field  is  mandatory  for 

envelopes  transferred  between 
MTAs  within  a  PRMD,  and 
prohibited  in  messages 
transferred  outside  the  domain. 
(See  Note  1) 


Notes 

1    The  M  classification  is  only  applicable  if  an  implementation  is 
claiming  conformance  according  to  clause  10.2. 


7.5.3       Reliable  Transfer  Server  (RTS) 

In  the  pUserData  of  PConnect,  the  value  of  appllcationProtocol  should  be  1.  This  value  was  chosen 
because  the  agreements  on  intra-domain  connections  are  not  strictly  PI,  nor  are  they  MOTIS. 
Philosophically,  it  would  be  good  to  choose  a  new  application  protocol  identifier  for  these  agreements, 
but  this  introduces  too  many  practical  problems.  Since  these  agreements  are  closer  to  P1  than  to 
MOTIS,  the  value  of  1  will  be  used.  This  will  not  cause  interworking  problems  between  domains,  because 
the  only  deviation  from  P1  is  the  InternalTracelnfo,  which  will  not  be  present  in  messages  transferred 
outside  of  a  domain. 


8     Error  Handling 

This  clause  describes  appropriate  actions  to  be  taken  upon  receipt  of  protocol  elements  which  are  not 
supported  in  this  profile,  malformed  MPDUs,  unrecognized  0/R  Name  forms,  content  errors,  errors  in 
reports,  and  unexpected  values  for  protocol  elements. 


8.1      MPDU  Encoding 

The  MPDU  should  have  a  context-specific  tag  of  0,  1 ,  or  2.  If  it  does  not  have  one  of  these  tags,  it  is  not 
possible  to  figure  out  who  originated  the  message.  Therefore,  the  way  this  error  is  reported  is  a  local 
matter. 
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8.2  Contents 

Once  delivery  to  the  UA  has  occurred,  it  is  not  possible  to  report  errors  in  P2  information  to  the 
originator.  In  addition,  it  seems  unreasonable  to  insist  that  the  MTA  that  delivers  a  message  ensure  that 
the  P2  content  of  the  message  is  acceptable.  As  a  result,  the  handling  of  content  errors  is  a  local  matter. 


8.3  Envelope 

This  clause  describes  the  handling  of  errors  in  message  envelopes.  Some  of  the  error  conditions 
described  below  may  be  detected  in  a  recipient's  0/R  Name.  This  may  limit  the  reporting  MTA's  ability 
to  generate  a  nondelivery  notification  that  accurately  reflects  the  erroneous  0/R  Name  in  the 
ReportedRecipientlnfo.  This  handling  of  this  situation  is  a  local  matter. 


8.3.1       Pragmatic  Constraint  Violations 

In  all  cases  of  pragmatic  constraint  violation,  a  nondelivery  report  should  be  generated  with  a 
ReasonCode  of  unableToTransfer,  and  a  DiagnosticCode  of  pragmaticGonstraintViolation. 


8.3.2       Protocol  Violations 

If  all  required  protocol  elements  are  not  present,  a  nondelivery  report  with  a  ReasonCode  of 
unableToTransfer  and  a  DiagnosticCode  of  protocolViolation  should  be  generated. 

If  a  protocol  element  is  expected  to  be  of  one  type,  but  is  encoded  as  another,  then  a  nondelivery  report 
with  a  ReasonCode  of  unableToTransfer  and  a  DiagnosticCode  of  invalidParameters  should  be 
generated. 


8.3.3       0/R  Names 

The  domain  that  has  responsibility  for  delivering  a  message  should  also  have  the  responsibility  to  send 
the  nondelivery  notification  if  the  message  cannot  be  delivered.  Therefore,  each  MTA  should  only 
validate  the  0/R  Names  of  recipients  with  responsibility  flags  set  to  TRUE.  In  addition,  a  nondelivery 
notification  can  only  be  sent  if  the  originator's  0/R  Name  is  valid. 

If  any  element  in  the  0/R  Name  is  unrecognized  or  if  the  CountryName,  AdministrationDomainName, 
and  one  of  PrivateDomainName  and  OrganizationName  (and,  for  ADMDs,  PersonalName  and 
OrganizationalUnit)  are  not  all  present,  then  a  nondelivery  report  should  be  generated  with  a 
ReasonCode  of  unableToTransfer,  and  a  DiagnosticCode  of  unrecognizedORName.  If  the  message  can 
be  delivered  even  though  the  ORName  is  invalid,  delivery  is  a  local  matter.  Note,  however,  that  if  the 
message  is  delivered,  the  invalid  ORName  might  be  propagated  through  the  X.400  system  (e.g.,  by 
forwarding). 

If  the  0/R  Name  has  all  of  the  appropriate  protocol  elements  and  the  message  still  cannot  be  delivered 
to  the  recipient,  the  following  DiagnosticCodes  may  appear  in  the  nondelivery  report: 
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unrecognizedORName.ambiguousORName.and  uaUnavailable. 


8.3.4  Tracelnformation 

Since  non-relaying  domains  need  not  do  loop  suppression,  domains  with  responsibility  for  delivering  the 
message  need  not  be  concerned  about  the  semantics  of  the  Tracelnformation,  that  is,  arrival  time  and 
converted  EncodedlnformationTypes  can  be  provided  to  the  UA  without  inspection  by  the  MTAs  of  the 
domain  as  long  as  the  Tracelnformation  is  properly  encoded  according  to  X.409. 

When  a  message  is  accepted  for  relay,  the  relaying  domain  must  check  that  a  Tracelnformation 
SEQUENCE  has  been  added  by  the  domain  that  last  handled  the  message.  If  the  appropriate 
Tracelnformation  was  not  added,  this  should  be  treated  as  a  protocolViolation  (sec.  8.3.2). 

In  addition,  the  relaying  domain  must  check  that  the  information  was  added  in  the  sequence  defined  by 
the  rules  for  adding  Tracelnformation  in  the  CCITT  X.400  Implementor's  Guide.  If  the  sequence  is 
invalid.then  a  nondelivery  report  should  be  generated  with  a  ReasonCode  of  unabieToTransfer  and  a 
diagnosticCode  of  invalidParameters. 

NOTE  -  It  would  be  desirable  for  the  CCITT  to  add  a  diagnostic  code  of  invalidTracelnformation  to  allow  a 
more  meaningful  description  of  this  problem.  A  request  for  this  new  diagnostic  code  will  be  submitted. 


8.3.5  InternalTracelnfo 

This  clause  applies  only  to  MTAs  which  follow  the  agreements  of  clause  7. 

When  a  message  is  accepted  for  relay  from  another  MTA  in  the  domain,  the  relaying  MTA  must  check 
that  an  InternalTracelnfo  SEQUENCE  has  been  added  by  the  MTA  that  last  handled  the  message.  If  the 
appropriate  InternalTracelnfo  was  not  added,  this  should  be  treated  as  a  protocolViolation  (sec.  8.3.2). 

In  addition,  the  relaying  MTA  must  check  that  the  information  was  added  in  the  sequence  defined  by  the 
rules  for  adding  Tracelnformation  in  the  CCITT  X.400  Implementor's  Guide.  If  the  sequence  is  invalid, 
then  a  nondelivery  report  should  be  generated  with  a  ReasonCode  of  unabieToTransfer  and  a 
diagnosticCode  of  invalidParameters. 

NOTE  -  It  would  be  desirable  for  the  CCITT  to  add  a  diagnostic  code  of  invalidTracelnformation  to  allow 
for  a  more  meaningful  description  of  this  problem.  A  request  for  this  new  diagnostic  code  will  be  submitted. 


8.3.6       Unsupported  X.400  Protocol  Elements 

The  protocol  elements  defined  in  X.400  but  unsupported  by  this  profile  are:  the  deferredDelivery  and 
PerDomainBilaterallnfo  parameters  of  the  UMPDUEnvelope,  the  ExplicitConversion  parameter  of 
Recipientlnfo,  and  the  alternateRecipientAllowed  and  contentReturnRequest  bits  of  the  PerMessageFlag. 
Appropriate  actions  are  described  below  for  domains  that  do  not  support  the  protocol  elements. 
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8.3.6.1  deferredDellvery 

The  delivering  domain  shall  do  one  of  the  following: 

a)  deliver  at  once, 

b)  hold  for  deferred  delivery, 

c)  return  a  nondelivery  notification  with  a  ReasonCode  of  unableToTransfer  and  a 
DiagnosticCode  of  noBilateralAgreement. 


8.3.6.2  PerDomainBilaterallnfo 

If  a  delivering  domain  receives  this  element,  the  element  can  be  ignored. 


8.3.6.3  ExplicltConverslon 

If  ExplicltConverslon  is  requested  the  message  should  be  delivered  if  possible.  That  is,  if  the  UA  is 
registered  to  accept  the  EncodedlnformationTypes  of  the  message,  then  the  message  should  be 
delivered  even  though  the  requested  conversion  could  not  be  performed  along  the  route.  If  delivery  is 
not  possible,  then  a  nondelivery  report  should  be  generated  with  a  ReasonCode  of 
conversionNotPerformed  with  no  DiagnosticCode. 


8.3.6.4  alternateReciplentAllowed 

If  a  delivering  domain  receives  this  element  the  element  can  be  ignored. 


8.3.6.5  contentReturnRequest 

If  a  delivering  domain  receives  this  element,  the  element  can  be  ignored. 


8.3.7       Unexpected  Values  for  INTEGER  Protocol  Elements 

There  are  three  INTEGERS  in  the  P1  Envelope.  Appropriate  actions  are  described  below  for  domains 
receiving  unexpected  values  for  Priority,  ExplicitConversion,  and  ContentType. 


8.3.7.1  Priority 

Additional  values  for  Priority  have  been  suggested  by  at  least  one  group  of  implementors  as  upward 
compatible  changes  to  the  X.400  Recommendations.  Therefore,  if  a  PRMD  receives  an  unexpected  value 
for  Priority,  and  this  value  is  greater  than  one  byte  in  length,  a  nondelivery  report  should  be  generated 
with  a  ReasonCode  of  unableToTransfer  and  DiagnosticCode  of  invalid  Parameters.  If  the  value  is  less 
than  or  equal  to  one  byte,  the  PRMD  can  either  generate  a  nondelivery  report  as  previously  specified  or 
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8.3.7.2  ExplicitConversion 

When  an  unexpected  value  is  received  for  ExplicitConversion,  it  should  be  handled  as  in  clause  8.3.6.3. 


8.3.7.3  ContentType 

If  the  ContentType  is  not  supported  by  the  delivering  MTA,  then  a  nondelivery  report  should  be 
generated  with  a  ReasonCode  of  unableToTransfer,  and  a  DiagnosticCode  of  contentTypeNotSupported. 


8.3.8       Additional  Elements 

In  the  absence  of  multilateral  agreements  to  the  contrary,  receipt  of  privately  tagged  elements  and 
protocol  elements  in  addition  to  those  defined  in  X.400  will  result  in  a  nondelivery  report  with  a 
ReasonCode  of  unableToTransfer  and  a  DiagnosticCode  of  invalidParameters. 

The  exceptions  to  this  are  the  MOTIS  elements.  The  treatment  of  MPDU's  containing  these  MOTIS 
extensions  is  described  in  clause  6.11. 


8.4  Reports 

There  is  no  mechanism  for  returning  a  delivery  or  status  report  due  to  errors  in  the  report  itself. 
Therefore  the  handling  of  errors  in  reports  is  a  local  matter. 


9     MHS  Use  of  Directory  Services 


9.1      Directory  Service  Elements 

Recommendation  X.400  recognizes  the  need  of  MHS  users  for  a  number  of  directory  service  elements. 
Directory  service  elements  are  intended  to  assist  users  and  their  UAs  in  obtaining  information  to  be  used 
in  submitting  messages  for  delivery  by  the  MTS.  The  MTS  may  also  use  directory  service  elements  to 
obtain  information  to  be  used  in  routing  messages.  Some  functional  requirements  of  directories  have 
been  identified  and  are  listed  below: 

a)  Verify  the  existence  of  an  0/R  name. 

b)  Return  the  0/R  address  that  corresponds  to  the  0/R  name  presented. 

c)  Determine  whether  the  0/R  name  presented  denotes  a  user  or  a  distribution  list. 

d)  Return  a  list  of  the  members  of  a  distribution  list. 
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e)  When  given  a  partial  name,  return  a  list  of  0/R  nanne  possibilities. 

f)  Allow  users  to  scan  directory  entries. 

g)  Allow  users  to  scan  directory  entries  selectively. 

h)  Return  the  capabilities  of  the  entity  referred  to  by  the  0/R  name. 

i)  Provide  maintenance  functions  to  keep  the  directory  up-to-date. 

In  addition  to  functionality,  a  number  of  operational  aspects  must  be  considered.  These  include 
user-friendliness,  flexibility,  availability,  expendability,  and  reliability. 

Currently,  these  aspects  of  directory  service  elements  and  procedures  are  under  study  by  both  the 
CCITT  and  the  ISO.  Both  organizations  are  committed  to  the  development  of  a  single  Directory  Service 
specification  for  use  by  MHS  and  all  other  OSI  based  applications. 

Given  the  incomplete  nature  of  the  ongoing  activities  within  the  CCITT  and  the  ISO,  no  implementation 
details  will  be  provided  now  for  MHS  use  of  Directory  Services.  Implementation  agreements  for  MHS 
Use  of  Directory  Services  will  be  issued  when  current  activities  within  the  CCITT  and  the  ISO  are  stable. 


9.2      Use  of  Names  and  Addresses 

It  is  recognized  that  these  agreements  enable  a  wide  variety  of  naming  and  addressing  attributes  (see 
sec.  5.3.5  ORName  Protocol  Elements)  wherein  each  PRMD  may  adopt  particular  routing  schemes 
within  its  domain. 

With  the  exception  of  the  intra-domain  connection  agreements: 

a)  These  agreements  make  no  attempt  to  recommend  a  standard  practice  for  electronic  mail 
addressing. 

Inter-PRMD  addressing  may  be  secured  according  to  practices  outside  the  scope  of  these  agreements, 
such  as: 

a)  manual  directories 

b)  on-line  directories 

c)  ORName  address  specifications 

d)  ORName  address  translation. 

Further,  each  PRMD  may  adopt  naming  and  addressing  schemes  wherein  the  user  view  may  take  a  form 
entirely  different  from  the  attributes  reflected  in  table  9.  And,  each  PRMD  may  have  one  user  view  for  the 
originator  form  and  another  for  the  recipient  form,  and  perhaps  other  forms  of  user  addressing.  In  some 
cases  (e.g.,  receipt  notification)  these  user  forms  must  be  preserved  within  the  constraints  of  these 
implementation  agreements.  However,  mapping  between  one  PRMD  user  form  to  another  PRMD  user 
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form,  via  the  X.400  ORName  attributes  of  tiiese  agreements,  is  outside  tfie  scope  of  tfiese  agreements. 


10  Conformance 


10.1  Introduction 

In  order  to  ensure  tliat  products  conform  to  tfiese  implementation  agreements,  it  is  necessary  to  define 
the  types  and  degrees  of  conformance  testing  that  products  must  pass  before  they  may  be  classified  as 
conformant.  This  clause  defines  the  conformance  requirements  and  provides  guidelines  for  the 
interpretation  of  the  results  from  this  type  of  testing. 

This  clause  is  incomplete  and  will  be  enhanced  in  future  versions  of  this  Agreement.  Later  versions  will 
reflect  the  problems  of  conformance  testing  and  will  outline  specific  practices  and  recommendations  to 
aid  the  development  of  conformance  tests  and  procedures. 


10.2    Definition  of  Conformance 

For  this  clause,  the  term  conformance  is  defined  by  the  following: 

a)  The  tests  indicated  for  this  clause  are  intended  to  establish  a  high  degree  of  confidence  in  a 
:<     statement  that  the  implementation  under  test  (lUT)  conforms  (or  does  not  conform)  to  the 

agreements  of  this  clause. 

b)  Conformance  to  a  service  element  means  that  the  information  associated  with  the  service 
element  is  made  accessible  to  the  user  (person  or  process)  whenever  this  agreement  says  that 
this  information  should  be  available.  Accessible  means  that  information  must  be  provided 

,    ;     describing  how  a  user  (person  or  process): 

1)  causes  appropriate  information  to  be  displayed,  or 

2)  causes  appropriate  information  to  be  obtained. 

c)  Conformance  to  P1,  P2,  and  RTS  as  part  of  an  X.400  OSI  application  requires  that  only  the 
external  behavior  of  that  OSI  system  adheres  to  the  relevant  protocol  standards.  In  order  to 
achieve  conformance  to  this  clause,  it  is  not  required  that  the  inter-layer  interfaces  be  available 
for  testing  purposes. 

d)  Conformance  to  the  protocols  requires: 

1)  that  MPDUs  correspond  to  instances  of  syntactically  correct  data  units, 

2)  MPDUs  in  which  the  data  present  in  the  fields  and  the  presence  (or  absence)  of 
those  fields  is  valid  in  type  and  semantics  as  defined  in  X.400,  as  qualified  by  this  profile, 

3)  correct  sequences  of  protocol  data  units  in  responses  (resulting  from  protocol 
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procedures). 

e)  Statements  regarding  the  conformance  of  any  one  implementation  to  this  profile  are  not 
complete  unless  a  Protocol  Implementation  Conformance  Statement  (PICS)  is  supplied. 

f)  The  term  "Implementation  Under  Test"  (lUT)  is  interchangeable  with  the  term  "system"  in  the 
definition  of  conformance,  and  may  refer  to: 

1 )  a  domain,  which  may  be  one  or  more  MTA's  with  co-located  or  remote  U A's, 

2)  a  single  instance  of  an  MTA  and  co-located  UA  with  X.400  (P1,  P2,  RTS  and  session) 
software, 

3)  a  relaying  product  with  PI,  RTS  and  session  software, 

4)  a  gateway  product. 

g)  Claiming  Implementation  Conformance 

1)  An  implementation  which  claims  to  be  conformant  as  an  ADMD  must  adhere  to  the 
agreements  in  clauses  5  and  6. 

2)  An  implementation  which  claims  to  be  conformant  as  a  PRMD  must  adhere  to  the 
agreements  in  clause  5. 

3)  An  implementation  which  claims  to  be  conformant  as  a  relaying  PRMD  must  adhere 
to  the  agreements  in  clause  5  and  the  appropriate  clauses  of  7. 

4)  An  implementation  which  claims  to  be  conformant  to  the  intra-domain  connection 
agreements  must  adhere  to  the  agreements  in  clause  5  and  the  appropriate  clauses  of 
7. 


10.3    Conformance  Requirements 


10.3.1  Introduction 

Conformance  to  this  specification  requires  that  all  the  services  listed  as  supported  in  clauses  5,  6,  and  if 
appropriate,  7  of  these  agreements  are  supported  in  the  manner  defined,  in  either  the  CCITT  X.400 
Recommendations  or  these  agreements.  It  is  not  necessary  to  implement  the  recommended  practices  of 
annex  B,  in  order  to  conform  to  these  agreements. 

It  is  the  intention  to  adopt,  where  and  when  appropriate  the  testing  methodology  and/or  the  abstract 
test  scenarios  currently  being  defined  by  the  CCITT  X.400  Conformance  Group.  However,  it  is 
recognized  that  formal  CCITT  Recommendations  relating  to  X.400  Conformance  Testing  will  not  be 
available  until  1988.  It  is  also  recognized  that  aspects  of  these  agreements  are  outside  the  scope  of  the 
CCITT,  and  that  other  organizations  will  have  to  provide  conformance  tests  in  these  cases. 
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This  clause  is  intended  to  provide  guidelines  to  vendors  who  envisage  having  X.400  products  available 
prior  to  any  formal  nnechanism,  or  "Conformance  Test  Center"  being  made  accessible  that  would  allow 
for  conformance  to  this  product  specification  to  be  tested. 

It  is  feasible  that  vendors  and  carriers  will  want  to  enter  bilateral  test  agreements  that  will  allow  for  initial 
trials  to  be  carried  out  for  the  purposes  of  testing  initial  interworking  capabilities.  It  is  equally  feasible  that 
for  the  purposes  of  testing  interoperability,  only  a  subset  of  this  specification  will  initially  be  tested. 

NOTE  -  By  claimirig  conformance  to  this  subset  of  information  the  vendor  or  carrier  CANNOT  claim 
conformance  to  this  entire  specification. 

There  are  two  aspects  to  the  requirements,  interworking  and  service,  as  described  in  the  following 
clauses. 


10.3.2.1  Interworking 

The  interworking  requirements  for  conformance  implies  that  tests  be  done  to  check  for  the  syntax  and 
semantics  of  protocol  data  elements  for  a  system  as  defined  by  the  classification  scheme  of  clauses 
5.2.1.1  and  7.5.2.  For  a  relay  system,  the  correct  protocol  elements  should  be  relayed  as  appropriate. 
For  a  recipient  system,  a  message  with  correct  protocol  elements  must  not  be  rejected  where 
appropriate. 


10.3.2.2  Service 

For  information  available  to  the  recipients  via  the  IPMessage  Heading  and  Body,  the  following  should  be 
made  accessible: 


a) 

IPMessage  ID  -  only  the  PrintableString  portion  of  the  IPMessageld  needs  to  be  accessible. 

b) 

subject. 

c) 

primaryRecipients, 

d) 

copyRecipients, 

e) 

blindcopyRecipients, 

f) 

authorizinglisers, 

g) 

originator. 

h) 

InReplyTo, 

replyToUsers, 
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j)  importance, 

k)  sensitivity, 

I)  lASText  Bodypart. 
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Annex  A  (normative) 

Interpretation  of  X.400  Service  Elements 

The  work  on  service  element  definitions  is  limited  to  those  that  are  defined  as  'supported'  in  clause  5  of 
this  specification.  Furthermore  it  is  not  the  intent  of  this  clause  to  define  how  information  should  be 
made  available  or  presented  to  a  MHS  user,  nor  is  it  intended  to  define  how  individual  vendors  should 
design  their  products.  In  addition,  statements  on  conformance  to  a  specific  service  element  and  the 
allocation  of  error  codes  that  are  generated  as  a  result  of  violations  of  the  service  should  be  defined  in 
the  clauses  on  conformance  and  errors  as  part  of  the  main  product  specification.  The  main  objective  is 
to  provide  clarification,  where  required,  on  the  functions  of  a  service  element,  and  in  particular  what  the 
original  intent  of  the  Recommendations  were. 


A.I      Service  Elements 

The  following  Service  Elements  defined  in  X.400  have  been  examined  and  require  further  text  to  be 
added  to  their  definitions  to  represent  the  proposed  implementation  of  these  service  elements  by  the 
X.400  SIG. 

The  service  element  clarifications  are  to  be  taken  in  the  context  of  this  profile. 
Service  elements  not  referenced  in  this  clause  are  as  defined  in  X.400. 


A.2  Probe 

A  PRMD  need  not  generate  probes. 

If  a  probe  is  addressed  to  and  received  by  a  PRMD,  the  PRMD  must  respond  with  a  Delivery  Report  as 
appropriate  at  the  time  the  probe  was  processed. 


A.3      Deferred  Delivery 

In  the  absence  of  bilateral  agreements  to  the  contrary,  Deferred  Delivery  and  Deferred  Delivery 
Cancellation  are  local  matters  (i.e.,  confined  to  the  originating  domain)  and  need  not  be  provided. 

The  extension  of  Deferred  Delivery  beyond  the  boundaries  of  the  initiating  domain  is  via  bilateral 
agreement  as  specified  in  section  3.4.2.1  of  X.411. 
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A.4     Content  Type  Indication 

It  is  required  that  both  an  originating  and  recipient  domain  be  able  to  support  P2  content  type.  The 
ability  for  domains  to  be  able  to  exchange  content  types  other  than  P2  will  depend  on  the  existence  of 
bilateral  or  multi-lateral  agreements. 


A.5     Original  Encoded  Information  Types  Indication 

It  is  required  that  both  an  originating  and  recipient  domain  be  able  to  support  IA5  text.  Support  for  other 
encoded  information  types,  for  the  purposes  of  message  transfer  between  domains,  will  depend  on  the 
existence  of  bilateral  or  multi-lateral  agreements. 

The  use  of  the  'unspecified'  form  of  encoded  information  type  should  only  be  used  when  the  UMPDU 
content  represents  an  SR-UAPDU  or  contains  an  auto-forwarded  IM-UAPDU. 

The  original  encoded  information  type  of  a  message  is  not  meaningful  unless  a  message  is  converted  en 
route  to  the  recipient.  These  agreements  support  only  IA5  text,  which  should  not  undergo  conversion. 
The  original  encoded  information  types  should  be  made  accessible  to  the  recipient  for  upward 
compatibility  with  the  use  of  non-IA5  text  message  body  parts. 


A.6      Registered  Encoded  Information  Types 

A  UMPDU  with  an  'unspecified'  value  for  Original  Encoded  Information  Type  shall  be  delivered  to  the  UA. 


A.7      Delivery  Notification 

The  UAContentID  may  be  used  by  the  recipient  of  the  delivery  notification  for  correlation  purposes. 


A.8      Disclosure  of  Other  Recipients 

This  service  is  not  made  available  by  originating  MTAE's  to  UAE's,  but  must  be  supported  by  relaying 
and  recipient  MTAE's. 

By  supporting  the  disclosure  of  other  recipients  the  message  recipient  can  be  informed  of  the  0/R 
names  of  the  other  recipient(s)  of  the  message,  as  defined  in  the  PI  envelope,  in  addition  to  the  0/R 
Descriptors  within  the  P2  header. 

These  agreements  do  not  support  initiation  of  disclosure  of  other  recipients,  but  the  information 
associated  with  it  should  be  made  accessible  to  the  recipient  for  upward  compatibility  with  support  for 
the  initiation  of  this  service  element. 
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A.9     Typed  Body 

As  defined  in  X.400  with  the  addition  of  the  Private  Body  Types  that  are  to  be  supported.  At  present 
there  is  no  mechanism  provided  within  X.420  that  would  allow  you  to  respond  to  reception  of  an 
unsupported  body  type. 

Action  taken  in  this  situation  is  a  local  matter. 


A.10    Blind  Copy  Recipient  Indication 

It  should  be  considered  that  the  recipient's  UA  acts  on  behalf  of  the  recipient,  and  therefore  may  choose 
to  disclose  all  BCC  recipients  to  each  other.  Therefore  it  is  the  responsibility  of  the  originating  domain  to 
submit  two  or  more  messages,  depending  on  whether  or  not  each  BCC  should  be  disclosed  to  each 
other  BCC. 


A.11    Auto  Forwarded  Indication 

A  UA  may  choose  not  to  forward  a  message  that  was  previously  auto-forwarded.  In  addition  there  is  no 
requirement  for  an  IPM  UA  that  does  not  support  non-receipt  or  receipt  notification  to  respond  with  a 
non-receipt  notification  when  a  message  is  auto-fonA/arded. 


A.12    Primary  and  Copy  Recipients  Indication 

It  is  required  that  at  least  one  primary  recipient  be  specified;  however,  for  a  forwarded  message  this 
need  not  be  present.  The  recipient  UA  should  be  prepared  to  accept  no  primary  and  copy  recipients  to 
enable  future  interworking  with  Teletex,  Fax,  etc. 


A.I  3    Sensitivity  Indication 

A  message  originator  should  make  no  assumptions  as  to  the  semantic  interpretation  by  the  recipients 
UA  regarding  classifications  of  sensitivity.  For  example,  a  personal  message  may  be  printed  on  a  shared 
printer. 


A.I 4    Reply  Request  Indication 

In  requesting  this  service  an  originator  may  additionally  supply  a  date  by  which  the  reply  should  be  sent 
and  a  list  of  the  intended  recipients  of  the  reply.  If  no  such  list  is  provided  then  the  initiator  of  the  reply 
sends  the  reply  to  the  originator  of  the  message  and  any  recipients  the  reply  initiator  wishes  to  include. 
The  replytoUsers  and  the  replyBy  date  may  be  specified  without  any  explicit  reply  being  requested.  This 
may  be  interpreted  by  the  recipient  as  an  implicit  reply  request.  Note  that  for  an  auto-forwarded 
message  an  explicit  or  implicit  reply  request  may  not  be  meaningful. 
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A.I  5    Body  Part  Encryption 

The  original  encoded  information  type  indication  includes  the  encoded  information  type(s)  of  message 
body  parts  prior  to  encryption  by  the  originating  domain.  The  ability  for  the  recipient  domain  to  decode 
an  encrypted  body  part  is  a  local  matter.  Successful  use  of  this  facility  can  only  be  guaranteed  if  there 
exists  bilateral  agreements  to  support  the  exchange  of  encrypted  body  parts. 


A.I  6    Forwarded  IP  Message  Indication 

The  following  use  of  the  original  encoded  information  type  in  the  context  of  forwarded  messages  is 
clarified: 

a)  If  fon/varding  a  private  message  body  part  the  originator  of  the  fonwarded  message  shall  set 
the  original  encoded  information  types  in  the  P1  envelope  to  undefined  for  that  body  part. 

b)  The  encoded  information  types  of  the  message  being  forwarded  should  be  reflected  in  the 
new  original  encoded  information  types  being  generated. 

c)  See  ammex  B  on  recommended  practices  for  the  use  of  the  delivery  information  as  part  of 
Forwarded  IP-message. 


A.17    Multipart  Body 

It  is  the  intent  of  multipart  bodies  to  allow  for  the  useful  and  meaningful  structuring  of  a  message  that  is 
constructed  using  differing  body  part  types.  For  example,  it  is  not  recommended  that  a  message  made 
up  of  only  IA5  text  should  be  represented  as  a  number  of  IA5  body  parts,  each  one  representing  a 
paragraph  of  text. 
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Annex  B  (informative) 
Recommended  X.400  Practices 

It  is  not  necessary  to  follow  the  recommended  practices  when  claiming  conformance  to  these 
agreements. 


B.I      Recommended  Practices  in  P2 


B.1.1  ORDescrlptor 

Vendors  following  the  OSI  Implementors'  Workshop  guidelines  shall,  whenever  possible,  generate  the 
ORName  portion  of  an  ORDescrlptor  in  ALL  IPM  heading  fields. 


B,1.2       ForwardedlPMessage  BodyParts 

ForwardedlPMessage  BodyParts  should  be  nested  no  deeper  than  eight.  There  is  no  restriction  on  the 
number  of  ForwardedlPMessage  BodyParts  at  any  given  depth. 


B.I. 3  Deliverylnformatlon 

It  is  strongly  recommended  that  Deliverylnformatlon  be  supplied  in  both  forwarded  and  autoforwarded 
message  body  parts.  Deliverylnformatlon  is  useful  when  a  message  has  multiple  forwarded  message 
body  parts  because  without  it,  the  EncodedlnformationType(s)  of  the  component  forwarded  messages 
cannot  be  deduced  easily.  Deliverylnformatlon  is  useful  for  autoforwarded  messages  because  the 
EncodedlnformationType  of  an  autoforwarded  message  is  "unspecified"  and  the 
EncodedlnformationType(s)  of  the  message  cannot  be  determined  easily  without  it.  Absence  of  the 
EncodedlnformationType(s)  makes  it  difficult  for  a  UA  to  easily  determine  whether  the  message  can  be 
rendered. 


B.2      Recommended  Practices  in  RTS 


B.2.1  S-U-ABORT 

In  the  case  where  S-U-ABORT  indicates  a  temporaryProblem,  reestablishment  of  the  session  should  not 
be  attempted  for  a  "sensible"  time  period  (typically  not  less  than  5  min).  In  instances  where  this  delay  is 
not  required  or  necessary,  report  a  localSystemProblem. 
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B.2.2 


S-U-EXCEPTION-REPORT 


S-U-EXCEPTION-REPORT  reason  ccxies  can  be  interpreted  as  follows: 


B.2.2.1 


receiving  ability  jeopardized  (value  1) 


Possible  meaning:  The  receiving  RTS  knows  of  an  impending  system  shutdown. 


B.2.2.2 


local  ss-User  error  (value  5) 


Possible  meaning:  The  receiving  RTS  needs  to  resynchronize  the  session  dialogue. 


B.2.2.3 


irrecoverable  procedure  error  (value  6) 


Possible  meaning:  The  receiving  RTS  has  had  to  delete  a  partially  received  APDU,  even  though  some 
minor  synchronization  points  have  been  confirmed. 


Possible  meaning:  The  receiving  RTS  cannot  handle  the  APDU  (for  example,  because  it  was  too  large) 
and  wishes  to  inform  the  sending  RTS  not  to  try  again. 


Possible  meaning:  The  S-ACTIVITY-RESUME  request  specified  a  minor  synchronization  point  serial 
number  which  does  not  match  the  checkpoint  data. 


B.2.3       OS!  Addressing  Information 

For  purposes  of  identifying  an  MTA  during  an  RTS  Open,  OSI  addressing  information  should  be  used. 
This  addressing  information  is  conveyed  by  lower  layer  protocols  and  is  reflected  by  the  calling  and 
called  SSAP  parameters  of  the  S-CONNECT  primitives. 

MTA  validation  and  identification  are  related,  but  separate,  functions.  The  mTAName  and  password 
protocol  elements  of  the  RTS  user  data  should  be  used  for  validation,  rather  that  identification,  of  an 
MTA.  The  RTS  initiator  and  responder  may  independently  require  each  other  to  supply  mTAName  and 
password. 

The  CallingSSUserReference  parameter  of  the  S-CONNECT  primitives  should  only  have  meaning  to  the 
entity  that  encoded  it  and  should  not  be  used  to  identify  an  MTA. 


B.2.2.4 


non  specific  error  (value  0) 


B.2.2.5 


sequence  error  (value  3): 
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B.3     Recommended  Practices  for  ORName 

Table  9  stipulates  that  the  StandardAttrlbuteList  must  contain  either  PrivateDomainName  or 
OrganizationName.  It  is  recommended  that,  for  both  originator  and  recipients  in  a  private  domain,  the 
PrivateDomainName  field  be  used. 

It  is  recommended  that  there  should  be  a  DomainDefinedAttribute  to  be  used  in  addressing  UAs  in 
existing  mail  systems,  in  order  to  curtail  the  proliferation  of  different  types  of  DomainDefinedAttributes 
used  for  the  same  purpose.  The  syntax  of  this  DomainDefinedAttribute  conforms  to  the  CCITT  Pragmatic 
Constraints,  and  thus  has  a  maximum  value  length  of  128  octets  and  a  type  length  of  8  octets,  each  of 
type  Printable  String.  Only  one  occurrence  is  allowed. 

This  DomainDefinedAttribute  has  the  type  name  "ID"  (in  uppercase).  It  contains  the  unique  identifier  of 
the  UA  used  in  addressing  within  the  domain.  This  DomainDefinedAttribute  is  to  be  exclusively  used  for 
routing  within  the  destination  domain  (i.e.,  once  routed  to  that  domain  via  the  mandatory  components  of 
the  StandardAttrlbuteList);  any  other  components  of  the  StandardAttrlbuteList  may  be  provided.  If  they 
conflict  delivery  is  not  made. 

The  contents  of  this  parameter  need  not  be  validated  in  the  originating  domain  or  any  relaying  domain, 
but  simply  transferred  intact  to  the  next  MTA  or  domain. 

Class  2  and  class  3  MTAs  in  a  PRMD  should  allow  administrators  to  decide  the  number  of 
OrganizationalUnits  that  should  appear  in  user  names,  instead  of  imposing  a  software  controlled  limit 
which  is  less  than  four.  This  is  desirable  because  when  two  different  vendors  impose  different  limits  on 
the  number  of  OrganizationalUnits  in  a  name,  it  becomes  difficult  for  the  administrator  to  choose  a 
sensible  naming  scheme. 

There  are  existing  mail  systems  that  include  a  small  set  of  non-Printable  String  characters  in  their 
identifiers.  For  these  systems  to  communicate  with  X.400  messaging  systems,  either  for  pass-through 
service  or  delivery  to  X.400  users,  gateways  will  be  employed  to  encode  these  special  characters  into  a 
sequence  of  Printable  String  characters.  This  conversion  should  be  performed  by  the  gateway 
according  to  a  common  scheme  and  before  insertion  in  the  ID  DDA,  which  is  intended  to  carry 
electronic  mail  identifiers.  X.400  User  Agents  may  also  wish  to  perform  such  conversions. 

It  is  recommended  that  the  following  symmetrical  encoding  and  decoding  algorithm  for  non-Printable 
String  characters  be  employed  by  gateways.  The  encoding  algorithm  maps  an  ID  from  an  ASCII 
representation  to  a  PrintableString  representation.  Any  non-printable  string  characters  not  specified  in  the 
table  are  covered  by  the  category  "other"  in  the  table  below. 

The  principal  conversion  table  for  the  mapping  is  as  follows: 
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Table  B.I  -  Printable  String  to  ASCII  Mapping 


ASCII  Character 

Printable  String  Character 

%  (percent) 

(P) 

@  (at  sign) 

(a) 

1  (exclamation) 

(b) 

"  (quote  mark) 

(q) 

_  (underline) 

(u) 

(  ( left  paren. ) 

(1) 

)   (right  paren. ) 

(r) 

other 

(3DIGIT) 

where  3DIGIT  has  the  range  000  to  377  and  is  interpreted  as  the  octal  encoding  of  an  ASCII  character. 

To  encode  an  ASCII  representation  to  a  PrintableString,  the  table  and  the  following  algorithm  should  be 
used: 


IF  current  character  is  in  the  encoding  set 

THEN 

encode  the  character  according  to  the  table 

above 

ELSE 

write  the  current  character; 

continue  reading; 

To  decode  a  PrintableString  representation  to  an  ASCII  representation,  the  table  and  the  following 
algorithm  should  be  used: 


IF  current  character  is  not  "("  THEN 
write  character 

ELSE 

{ 

look  ahead  appropriate  characters; 

IF  composite  characters  are  in  the  above  table  THEN 

decode  per  above  table 
ELSE 

write  current  character; 

} 

continue  reading; 


Class  2  and  class  3  MTAs  In  a  PRMD  should  allow  administrators  to  decide  the  number  of 
OrganizationalUnits  that  should  appear  in  user  names,  instead  of  imposing  a  software  controlled  limit 
which  is  less  than  four.  This  is  desirable  because  when  two  different  vendors  impose  different  limits  on 
the  number  of  OrganizationalUnits  in  a  name,  it  becomes  difficult  for  the  administrator  to  choose  a 
sensible  naming  scheme. 
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B.4      Postal  Addressing 

For  domains  wishing  to  support  postal  (or  pliysicai)  delivery  options,  the  following  interim  set  of 
"nationally-defined"  domain  defined  attributes  are  recommended.  The  CCITT  will  define  Standard 
Attributes  in  support  of  physical  delivery  in  its  1988  Recommendations;  this  is  only  an  interim  solution. 

CCITT  will  also  be  addressing  the  services  associated  with  physical  delivery.  This  interim  solution  does 
not  address  the  end-to-end  service  aspects  of  physical  delivery;  in  particular,  the  following  IPM  service 
elements  do  not  currently  extend  outside  of  the  X.400  environment: 

a)  alternate  Recipient  Assignment 

b)  PROBE 

c)  Receipt  Notification  /  Non-Receipt  Notifications 

d)  Grade  of  delivery 

"Delivery"  means  passing  a  message  from  the  MTS  to  the  physical  delivery  system  (PDS),  and  not  to  the 
user  (or  user  agent). 

The  following  three  DDAs  are  recommended  to  be  used  to  specify  a  postal  (or  physical)  address: 

CNTRPC  encodes  the  country  and  postal  code  for  postal  delivery.  The  DDA  value  is  of  the  form 
"Country? Postalcode"  (for  example,  "USA722096").  The  country  field  is  optional,  the  postal  code  is 
optional;  the  separator  ("?")  is  not.  If  both  country  and  postal  code  are  missing,  this  DDA  should  not  be 
specified. 

PDA1  The  country  and  postal  code  fields  are  free-form  text. 

PDA2  These  two  DDA  (signifying  Postal  Delivery  Address  strings  1  and  2)  form  a  256  character  free- 
form  postal  address.  Fields  are  separated  by  a  question  mark  ("?").  There  is  no  implied  separator 
between  PDA1  and  PDA2.  The  meaning  of  the  fields  are  defined  by  each  domain  supporting  the  physical 
delivery  interface.  PDA1  contains  the  first  128  characters,  PDA2  the  next  128  characters.  If  the  PDA 
string  is  less  than  1 28  characters,  PDA2  is  not  used. 

For  example,  if  the  domain  interprets  the  PDA  fields  as  lines,  the  address 

Mr.  John  Smith 
Conway  Steel 
123  Main  Street 
Reston  VA  22096 

would  be  encoded  as  follows: 
type      =  "PDAl" 

value    =  "Mr.  John  Smith?Conway  Steel?123  Main  Street?Reston  VA" 
CNTRPC  =  "722096" 
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B.5      EDI  use  of  X.400 


B.5.1       Introduction  and  Scope 

This  is  a  guideline  for  EDI  data  transfer  in  an  X.400  environment  conforming  to  the  NIST  agreements. 
These  recommended  practices  outline  procedures  for  use  in  transferring  EDI  transactions  between 
trading  partner  applications  in  an  attempt  to  facilitate  actual  X.400  implementation  by  EDI  users. 

The  scope  of  this  guideline  is  to  describe  specific  recommendations  for  adopting  X.400  as  the  data 
transfer  mechanism  between  EDI  applications. 


B.5.2  Model 


The  MHS  recommendations  can  accommodate  EDI  through  the  approach  illustrated  below.  Many 
Message  Transfer  (MT)  service  elements  defined  in  the  X.400  recommendations  are  particularly  useful  to 
the  EDI  application. 


x.400  Message  (1  EDI  interchange) 


Envelope 


— .  .  > 


PI  Control 
Information 


Content   > 


One 
EDI 

Interchange 


MHS  Message 


This  diagram  depicts  an  EDI  content  (1  EDI  interchange)  enveloped  by  the  P1  MHS  envelope.  All  the  MT 
Services  defined  in  the  X.400  Recommendations  may  be  used  for  EDI.  However,  it  is  not  required  to 
support  optional  or  non-essential  services  to  exchange  EDI  data  between  EDI  users.  When  an  EDI  user 
submits  an  EDI  Trade  Document  to  the  EDI  User  Agent,  the  EDI  UA  will  submit  the  EDI  content  plus  P1 
envelope  to  the  Message  Transfer  System  (MTS). 
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The  EDI  UA  must  support  the  essential  MT  Services  as  defined  in  these  Agreements;  for  example,  as  a 
minimum,  to  provide  default  values  for  services  not  elected  by  the  EDI  user,  such  as  Grade  of  Delivery. 

NOTE  -  MT  Services  are  not  necessarily  made  available  by  the  EDI  UA  to  the  EDI  user. 

B.5.3       Protocol  Elements  Supported  for  EDI 

The  follov\/ing  P1  protocol  elements  will  be  used  to  support  EDI  applications: 
B.5.3.1        Content  Type 

For  EDI  applications,  the  content  type  will  be  0  (undefined  content). 


B.5.3.2        Original  Encoded  Information  Types 

Any  EIT  defined  in  the  X.400  Recommendations  may  be  used  to  specify  the  encoding  of  EDI  content. 
However,  for  ANSI  X12  EDI  applications  in  particular,  it  is  expected  that  the  "undefined"  and  "laSText" 
EIT's  will  normally  be  used,  with  "undefined"  used  to  signify  the  EBCDIC  character  set. 


B.5.4       Addressing  and  Routing 

It  is  anticipated  that  connection  of  some  existing  systems  to  an  X.400  service  for  EDI  purposes  will  be  by 
other  than  X.400  protocols,  at  least  in  the  short  term. 

EDI  messages  entering  the  X.400  environment  will  therefore  need  to  have  X.400  0/R  Names  added  to 
identify  the  origination  and  recipient  trading  partners,  typically  by  means  of  local  directory  services  in  the 
origination  domain  which  will  map  EDI  identifiers/addresses  into  0/R  Names.  Such  0/R  Names  will 
contain  Standard  Attributes  as  defined  in  table  9  and  for  recipient  trading  partners  will  at  least  identify 
the  destination  domain. 

In  the  case  of  trading  partners  outside  the  X.400  environment,  it  is  expected,  however,  that  there  will  be 
cases  where  message  delivery  will  require  the  provision  of  addressing  information  beyond  that  which 
can  be  carried  in  Standard  Attributes.  In  such  cases.  Domain  Defined  Attributes  are  recommended  to  be 
used. 

The  syntax  of  this  DDA  is  as  defined  in  table  9,  with  a  single  occurrence  having  the  type  name  "EDI" 
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(uppercase)  and  a  value  containing  tfie  identifier/address  of  the  trading  partner.  For  ASC  X12  purposes, 
specifically,  this  value  will  comprise  the  2  digit  interchange  ID  qualifier  followed  by  the  Interchange  ID 
(max  15  characters).  Routing  on  this  DDA  shall  only  occur,  if  at  all,  in  the  destination  domain. 


B.6      USA  Body  Parts 

It  is  recommended  that  UAs  can  generate  any  USA  Body  Part,  as  defined  in  clause  5.3.6.2,  and  that  they 
can  receive  such  body  parts  as  well,  reception  of  USA  Body  Parts  does  not  imply  further  processing  by 
the  UA,  but  merely  that  the  body  part  is  made  available,  with  a  indication  of  its  registered  body  part 
identifier,  to  another  process  or  deposition  in  a  file.  Generation  implies  the  reverse  of  this  process. 


B.7     Recommended  Practices  for  Binary  Data  Transfer 

The  capability  to  transfer  binary  data,  such  as  those  generated  by  word/document  processing, 
spreadsheets,  or  graphics  applications  among  X.400  system  is  a  useful  and  desirable  feature.  Many 
messaging  systems  provide  such  capability  today. 

It  is  recommended  that  transfer  of  binary  data  through  1984-based  systems  be  achieved  using  the 
unidentified  BodyPart  in  P2  with  the  ASN1  definition  recaptured  as  follows: 


BodyPart 

: :=    CHOICE  { 

[0]   IMPLICIT  lASText 

[14]  IMPLICIT  Unidentified 
...  } 
: : =     OCTET  STRING 

Unidentified 

NOTE  -  the  Unidentified  BodyPart  is  included  in  1984  X.400  Implementor's  Guide,  Version  6,  and  is 
renamed  as  BilaterallyDefinedBodyPart  in  1988  X.400  Series  with  the  same  tag  and  definition. 

Additionally  the  binary  data  can  be  identified  by  a  text  string  in  the  subject  heading  or  in  an  lASText  body 
part  preceding  the  Unidentified  BodyPart. 

When  the  Unidentified  BodyPart  is  present  in  a  P2  message,  the  undefined(O)  bit  of  the  PI 
EncodedlnformationTypes  will  be  set.  If  the  lASText  bodypart  is  also  present,  the  IAStext(2)  bit  will  also  be 
set. 

The  binary  data  is  the  raw  data  as  generated  by  user  applications.  Besides  encapsulating  it  for  transfer 
purposes,  X.400  systems  do  not  encode  or  interprete  the  binary  data  in  any  way  further.  How  the  data  is 
encoded  or  decoded  is  defined  by  the  cooperating  user  applications.  How  the  data  is  injected  into  X.400 
systems  or  transferred  out  of  X.400  systems  to  the  user  applications,  or  how  the  user  applications  are 
invoked  to  process  the  data  is  a  local  implementation  issue  and  not  defined. 
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B.8      Recommended  Practice  for  Office  Document  Architecture 
(ODA)  Transfer 

It  is  recommended  that  the  conveyance  of  ODA  documents  through  1 984-based  X.400  systems  be 
achieved  using  the  following  schemes: 


B.8.1        ODA  In  P2 

An  ODA  document  will  be  transferred  as  a  single  body  part  with  tag  1 2,  recaptured  as  follows: 


BodyPart 

: : =    CHOICE  { 

[0]  IMPLICIT 

lASText 

oda 

[12]  IMPLICIT 

OCTET  STRING 

...  } 

The  content  of  the  Octet  String  will  contain  a  value  of  type  OdaBodyPart  as  follows: 


OdaBodyPart 

: : =     SEQUENCE  { 

OdaBodyPartParameters , 

OdaData  } 

The  Parameters  and  Data  components  are  defined  in  Annex  E  of  CCITT  Recommendation  T.411  (1988) 
(ISO  8613-1). 


B.8.2        ODA  In  PI 

The  undefined  bit  (bit  0)  of  the  EncodedlnformationTypes  must  be  set  and  the  ODA  bit  (bit  10)  of  the 
Encoded  I  nformationTypes  should  be  set  when  an  ODA  document  is  present  in  P2.  However,  MTAs 
should  be  tolerant  of  messages  containing  ODA  documents  being  received  with  just  the  undefined  bit 
(bit  0)  set,  and  should  still  deliver  the  message. 
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Annex  C  (normative) 

Rendition  of  lASText  and  T61  String  Characters 


C.I      Generating  and  Imaging  lASText 

The  characters  that  may  be  used  in  an  lASString  are  the  graphic  characters  (including  Space),  control 
characters  and  Delete  of  the  IA5  character  repertoire  ISO  646. 

The  graphic  characters  that  may  be  used  with  a  guaranteed  rendition  are  those  related  with  positions 
2/0  to  2/2,  2/5  to  3/15,  4/1  to  5/10,  5/15  and  6/1  to  7/10  in  the  basic  7-bit  code  table. 

The  other  graphic  characters  may  be  used  but  have  no  guaranteed  rendition. 

The  control  characters  that  may  be  used  but  have  no  guaranteed  effect  are  a  subset  consisting  of  the 
format  effectors  0/10  (LF),  0/12  (FF)  and  0/13  (CR)  provided  they  are  used  in  one  of  the  following 
combinations: 


CR 

LF 

to  Start  a  new  line 

CR 

FF 

to  start  a  new  page  (and  line) 

LF 

..  LF 

to  show  empty  lines  (always  after  one  of  the 

preceding  combinations). 

The  other  control  characters  or  the  above  control  characters  in  different  combinations  may  be  used  but 
have  no  guaranteed  effect. 

The  character  Delete  may  occur  but  has  no  guaranteed  effect.  The  IA5String  in  a  P2  IA5Text  BodyPart 
represents  a  series  of  lines  which  may  be  divided  into  pages.  Each  line  should  contain  from  0  to  80 
graphic  characters  for  guaranteed  rendition.  Longer  lines  may  be  arbitrarily  broken  for  rendition.  Note 
that  X.408  states  that  for  conversion  from  IA5Text  to  Teletex,  the  maximum  line  length  is  77  characters. 


C.2     Generating  and  Imaging  T61  String 

For  further  study. 
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Annex  D  (informative) 

Differences  in  Interpretation  Discovered  Through  Testing  of  the  MHS 
for  the  CeBit  1 987  Demonstration 

Several  interworking  problems  were  discovered  through  multi-vendor  testing.  These  problems,  and 
recommendations  for  solutions  to  them  are  discussed  in  this  annex. 


D.1      Encoding  of  RTS  User  Data 

The  password  is  defined  as  an  ANY  in  the  X.400  Recommendations,  and  implementor's  groups  have 
decided  to  use  an  lASString  for  this  field.  There  was  some  confusion  about  what  the  X.409  encoding  for 
this  lASString  would  be,  and  the  correct  encoding  is: 


class : 

context  specific 

form: 

constructor 

id  code: 

1 

length: 

length  of  contents 

contents: 

(primitive  encoding) 

lASString: 

16 

length: 

length  of  contents 

contents : 

the  password  string 

class : 

context  specific 

form: 

constructor 

id  code: 

1 

length: 

length  of  contents 

contents : 

(constructor  encoding)  left  as  an  exercise  for  the  reader 

Implementations  should  be  prepared  to  receive  any  X.409  type  for  the  password  because  of  its  definition 
as  an  ANY. 


D.2     Extra  Session  Functional  Units 

One  vendor  proposed  more  than  the  required  set  of  functional  units  on  opening  the  session  connection, 
and  the  receiver  rejected  the  connection.  All  debate  aside  about  whether  the  initiator  should  have 
proposed  units  outside  of  the  required  set,  or  whether  the  receiver  should  have  rejected  the  connection, 
the  set  of  functional  units  can  be  negotiated  in  a  straightfonArard  way.  The  following  is  recommended. 

If  the  initiator  proposes  using  more  than  the  required  set  of  functional  units,  the  responder  should 
specify  the  set  of  functional  units  that  it  would  like  to  use  (which  should  include  the  required  set)  in  the 
open  response.  The  session  implementations  will  automatically  use  the  intersection  of  the  units  proposed 
by  both  sides. 

If  the  initiator  proposes  using  less  than  the  required  set  of  functional  units,  the  responder  should  reject 
the  connection.  Unfortunately,  there  is  not  an  appropriate  RefuseReason  for  rejecting  the  connection,  so 
instead  of  refusing  the  connection  in  the  response  to  the  S-CONNECT,  the  receiver  should  issue  an  S-U- 
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ABORT  with  an  AbortReason  of  protocol  Error.  Note  that  it  is  valid  to  issue  an  S-U-ABORT  instead  of 
responding  to  the  S-CONNECT.  A  problem  report  has  been  submitted  to  the  CCITT  requesting  the 
addition  of  a  RefuseReason  for  this  situation. 

If  the  responder  proposes  using  less  than  the  required  set  of  functional  units,  the  session  connection  is 
established  before  the  initiator  can  check  for  this.  If  too  few  functional  units  have  been  proposed,  the 
initiator  should  abort  the  connection  using  S-U-ABORT,  with  an  abort  reason  of  protocolError. 


D.3     Mixed  Case  in  the  MTA  Name 

The  MTA  name  is  frequently  exchanged  over  the  telephone  when  two  systems  are  being  configured  to 
communicate  with  one  another.  In  one  such  telephone  exchange,  the  casing  of  the  MTA  name  was  not 
specified,  the  MTA  name  consisted  of  both  upper  and  lower  case  letters,  and  one  of  the  implementations 
compared  MTA  names  for  equality  in  a  case  sensitive  manner.  Consequently,  connections  failed  until  the 
problem  was  detected  and  repaired.  It  is  recommended  that  the  MTA  name  be  compared  for  equality  in 
a  case  insensitive  manner,  and  that  the  password  be  compared  for  equality  in  a  case  sensitive  manner. 


D.4     X.410  Activity  Identifier 

The  X.400  Implementor's  Guide  recommends  that  the  activity  identifier  be  X.409  encoded,  but  this  is  only 
a  recommendation  and  not  a  requirement.  Consequently,  receiving  systems  cannot  assume  that  the 
activity  identifier  will  be  X.409  encoded. 


D.5     Encoding  of  Per  Recipient  Flag  and  Per  Message  Flag 

In  the  definition  of  the  PerRecipientFlag  in  X.41 1,  there  is  a  statement  that  the  last  three  bits  are 
reserved,  and  should  be  set  to  zero.  It  is  unclear  whether  those  bits  are  unused  in  the  X.409  encoding. 
Receivers  should  accept  encodings  with  either  zero  or  three  unused  bits.  A  problem  report  has  been 
submitted  to  the  CCITT  asking  for  clarification. 

Though  there  is  not  any  statement  in  X.41 1  about  the  last  four  bits  of  the  PerMessageFlag,  some 
vendors  have  encoded  this  with  zero  unused  bits,  and  some  have  encoded  it  with  four  unused  bits.  The 
PerMessageFlag  should  be  encoded  with  at  least  four  unused  bits. 


D.6      Encoding  of  Empty  Bitstrings 

There  are  three  valid  encodings  for  an  empty  bitstring:  a  constructor  of  length  zero,  a  constructor  of 
indefinite  length  followed  by  the  end-of-contents  terminator,  and  a  primitive  of  length  one  with  a  zero 
octet  as  the  value. 
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D.7     Additional  Octets  for  Bitstrings 

Nothing  in  X.409  constrains  an  implementation  from  sending  two,  three,  four,  or  even  more  octets  for  a 
bitstring  that  fits  into  one  octet,  with  the  undefined  bits  set  to  zero.  Note  that  the  number  of  excess 
octets  is  bounded  by  the  pragmatic  constraints  guidelines  of  the  CCITT  X.400  Implementor's  Guide  for 
all  of  the  bitstrings  in  P1. 


D.8     Application  Protocol  Identifier 

If  a  value  other  that  1  is  received  in  the  applicationProtocol  of  the  pUserData  in  the  PConnect,  NIST 
implementations  will  reject  the  connection.  If  CEN/CENELEC  implementations  receive  a  value  other  than 
8883  for  this  field,  they  will  reject  the  connection.  This  is  an  unfortunate  state  of  affairs,  because  if  NIST 
implementations  accept  the  value  of  8883  without  supporting  the  MOTIS  service  elements,  they  would  be 
misrepresenting  themselves.  To  make  matters  worse,  CERT  uses  a  value  of  1,  but  relays  MOTIS 
elements,  which  means  that  MOTIS  elements  will  be  relayed  to  implementations  using  a  value  of  1  to 
demonstrate  that  they  do  not  support  MOTIS.  Work  is  continuing  to  try  to  find  a  solution  that  will  allow 
European  implementations  to  interwork  with  U.S  implementations. 


D.9     Initial  Serial  Number  in  S-CONNECT 

This  should  be  implemented  in  accordance  with  section  3.5.1  E4  of  the  Implementor's  Guide. 


D.10    Connection  Data  on  RTS  Recovery 

It  is  clarified  that  the  ConnectionData  is  identical  in  both  the  S-CONNECT.request  and  the  S- 
CONNECT.response.  The  value  of  the  ConnectionData  is  the  old  Session  Connection  Identifier. 


D.11    Activity  Resume 

If  an  activity  is  being  resumed  on  a  new  session  connection,  it  is  not  clear  from  X.410  and  X.225  whether 
all  four  of  the  called-ss-user  reference,  the  calling-ss-user  reference,  the  common  reference,  and  the 
additional  reference  information  should  be  specified  in  the  S-ACTIVITY-RESUME,  or  whether  one  of  the 
ss-user-references  should  be  absent.  It  is  also  unclear  whether  the  called-ss-user  reference  should  be 
identical  to  the  calling-ss-user  reference  if  both  are  present.  Consequently,  receivers  should  be  tolerant 
of  this  situation.  Appropriate  problem  reports  will  be  submitted  to  the  CCITT  asking  for  clarification. 
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D.I  2    Old  Activity  Identifier 

The  Old  Activity  identifier  in  S-ACTIVITY-RESUME  refers  to  tlie  original  activity  identifier. 


D.I  3    Negotiation  Down  to  Transport  Class  0 

For  European  implementations,  X.410  specifies  that  class  0  transport  must  be  supported.  However,  it  is 
permissible  for  an  initiator  to  propose  a  higher  class  as  the  preferred  class,  provided  that  class  0 
appears  as  the  alternate  class  in  the  T-Connect  PDU.  A  responding  implementation  can  choose  to  use 
either  the  preferred  or  alternate  class,  but  again,  must  be  able  to  use  class  0.  In  other  words,  for  private 
to  private  connections  in  Europe,  class  0  transport  is  required. 

This  conflicts  with  the  OIW  agreements,  since  class  0  is  only  required  if  one  of  the  partners  in  a 
connection  is  an  ADMD. 
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Annex  E  (informative) 

Worldwide  X.400  Conformance  Profile  Matrix 

Y  CONFORMANCE  (E)  implies  a  conformance  problem  for  European  products  in  the  United  States. 

Y  CONFORMANCE  (US)  implies  a  conformance  problem  for  U.S.  products  in  Europe. 
The  A/311  profile  is  specified  in  Env  41  202,  the  A/3211  profile  in  Env  41  201 

No  TTC  protocol  classification  for  RTS  exists. 

The  notation  X/Y  indicates  "X"  for  PRMDs  and  "Y"  for  ADMDs,  i.e.,  "M/G"  would  be  Mandatory  for 
PRMDs  and  Generatable  for  ADMDs. 


Table  E.I  -  Protocol  Element  Comparison  of  RTS 


RTS  element 

NIST 

A/311 

A/3211 

PROBLEM  Y/N 

PConnect 

M 

M 

M 

N 

DataTransf erSyntax 

M  0 

M  0 

M  0 

N 

PUserData 

M 

M 

M 

N 

checkpointSize 

H 

H 

H 

N 

windows i  ze 

H 

H 

H 

N 

dialogueMode 

H 

H 

H 

N 

connectdata 

M 

M 

M 

N 

appl i  cat  ionProtocol 

G  1 

H  1 

R  8883 

N 

H  8883 

Connect  ionData 

Open 

G 

G 

G 

N 

Recover 

G 

H 

G 

N 

Open 

RTSUserData 

G 

G 

G 

N 

Recover 

S  e  s  s  i  onConnec  t  i  onl D 

G 

G 

G 

N 

RTSUserData 

MTAName 

G 

G 

G 

N 

Password 

G 

G 

G 

N 

null 

G 

G 

G 

N 

Ses si onConnec tionID 

CallingUserReference 

M 

M 

M 

N 

CommonRe  f  e  r  enc  e 

M 

M 

M 

N 

AdditionalRef Info 

H 

H 

H 

N 

PAccept 

G 

G 

G 

N 

DataTransf erSyntax 

M  0 

M  0 

M  0 

N 
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Table  E.I  -  Protocol  Element  Comparison  of  RTS  (concluded) 


RTS  element 

NIST 

A/311 

A/3211 

PROBLEM  ( Y/N ) 

PUserData 

M 

M 

M 

N 

CheckpointSize 

H 

H 

H 

N 

WindowSize 

H 

H 

H 

N 

Connec  t  i  onDa  t  a 

M 

M 

M 

N 

PRefuse 

G 

G 

G 

N 

RefuseReason 

M 

M 

M 

N 

SSUserData 

G 

G 

G 

N 

(in  S-TOKEN-PLEASE) 

Abort Information 

G 

G 

G 

N 

(in  S-U- ABORT) 

AbortReason 

H 

H 

H 

N 

ref lectedParameter 

X 

X 

X 

N 
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Table  E.2  -  Protocol  Element  Comparison  of  Pi 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

ORname 

StandardAttributeList 

M 

M 

M 

M 

N  See  Note  4 

DomainDef AttributeList 

X 

X 

X 

G 

Y  See  Note  5 

StandardAttributeList 

Count  ryName 

R 

R 

R 

M 

N 

SO  R 

R 

N 

.121 

H 

Y  Conformance  (E) 

ther 

X 

Y  Prot  Vio 

Adm i n i s t r a t i onDoma i nName 

R 

R 

G 

M 

N 

...  if  PrintableString 

R 

G 

N 

...  if  numer icString 

H 

H 

Y  Conformance  (E) 

X.121  Address 

X 

X/R 

X 

Conf(uS)See  Note  1 

Terminal  ID 

X 

X/G 

X 

Conf(US)See  Note  1 

P  r  i  va  t  eDoma  i  nName 

G 

G 

G 

G 

N 

Organizati  onName 

G 

G 

G 

G 

N 

UniqueUAidentif ier 

X 

X/G 

X 

Conf(US)See  Note  1 

Per sonalName 

G 

G 

G 

G 

N 

OrganizationalUnit 

G 

G 

G 

G 

N 

Doma  i  nDe  f  i  nedAt  tribute 

X 

X 

X 

G 

N 

Type 

M 

M 

M 

M 

N 

Value 

M 

M 

M 

M 

N 

PersonalName 

Surname 

M 

M 

M 

M 

N 

GivenName 

G 

G 

G 

G 

N 

Initials 

G 

G 

G 

G 

N 

Gene  r  at  i  onQua 1 i  f  i  e  r 

G 

X 

X 

X 

Y  Conformance  (E) 

GlobalDomainldentif ier 

Count ryName 

M 

M 

M 

M 

N 

Adm  inistrati  onDoma  i  nName 

M 

M 

G 

M 

Y  Proto  Vio 

PrivateDomainldentif ier 

R/H 

H 

R 

M/X 

N 

MPDU 

UserMPDU 

G 

G 

G 

G 

Y  TTC  required 

MPDU  size  is 

32K 

De 1 i  ve  r yRepo  r  tMPDU 

G 

G 

G 

G 

N 

ProbeMPDU 

H 

H 

H 

H 

N 
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Table  E.2  -  Protocol  Element  Comparison  of  PI  (continued) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

UserMPDU 

UMPDUen ve 1 ope 

M 

M 

M 

M 

N 

UMPDUcontent 

M 

M 

M 

M 

N 

UMPDUenve lope 

MPDUidentif ier 

M 

M 

M 

M 

N 

originatorORname 

M 

M 

M 

M 

N 

or  i  g  i  na lEncodedTypes 

G 

H 

H 

G 

Y  Conformance  (E) 

ContentType 

M 

M 

M 

M 

N 

u 

11 

H 

11 

u 
n 

XI 

IN 

Priority 

G 

G 

G 

G 

N 

PerMessageFlag 

G 

G 

G 

G 

N 

Def erredDelivery 

X 

X 

X 

X 

N 

PprDoma  i  nBi 1 at  Tnf o 

X 

X 

X 

X 

N 

Recipient Info 

M 

M 

M 

M 

Y  TTC  MPDU  32K 

Traceinf ormat  ion 

M 

M 

M 

M 

N 

MOTIS->  LatestDelivery 

X 

N 

MOTIS->  InternalTracelnfo 

M/P 

P 

N 

UMPDUcontent 

M 

M 

M 

M 

N 

MPDUidentif ier 

GlobalDomainldent 

M 

M 

M 

M 

N 

IA5s t r  ino 

M 

M 

M 

M 

N 

PerMessageFlag 

DiscloseRecipients 

H 

@  MT 

H 

H 

Y  Conformance  (US) 

at  U 

? 

Y  Conformance  (US) 

ConversionProhibited 

G 

G 

G 

G 

N 

AlternatRecipAl lowed 

H 

@  MT 

H 

X 

Y  Conformance  (US) 

at  U 

Y  Conformance  (US) 

ContentReturnRequest 

X 

X 

X 

X 

MOTIS->  redirectionProhibited 

X 

N 

PerDomainBi lateral Info 

Count ryName 

M 

M 

M 

M 

N 

Admi  nDoma  i  nName 

M 

M 

G 

M 

y  Prot  Vio 

MOTIS->      PrivateDomai nName 

G 

N 

Bilaterallnfo 

M 

M 

M 

M 

N 
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Table  E.2  -  Protocol  Element  Comparison  of  PI  (continued) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

DeliveryReportContent 

original  MPDUident 

M 

M 

M 

M 

N 

intermediate  Trace 

X/G 

X 

X 

X 

Y  Conformance  (E) 

UAcontentID 

G 

G 

G 

G 

N 

M 

M 

M 

M 

Y  TTC  256  max 

returned 

H 

H 

X 

X 

Y  Conformance  (E) 

billing  information 

X 

X 

X 

X 

N 

Kepor ueuKecipien^inro 

recipient  ORname 

M 

M 

M 

M 

N 

extensionsldentif ier 

M 

M 

M 

M 

N 

PerRecipientFlag 

M 

M 

M 

M 

N 

LastTracelnformation 

M 

M 

M 

M 

N 

H 

H 

H 

H 

N 

Supplementary Info 

X/H 

X 

X 

X 

Y  Conformance  (E) 

MOTIS-> 

Reas s i gnment Inf o 

X 

N 

MOTIS-> 

Reas s i gnment Inf o 

MUTIS— > 

intendedRecipient 

M 

N 

MOTIS-> 

reasonForReassigmnent 

H 

N 

LastTracelnformation 

ar  r  i val 

M 

M 

M 

M 

N 

conve  r  t  edEnc Inf oType  s 

G 

G 

H 

G 

Y  Conformance  (E) 

Report 

M 

M 

M 

M 

N 

Report 

uexi  Versa  mro 

G 

G 

G 

N  See  Note  6 

NonDel i ver edinf o 

G 

G 

G 

N 

Del i veredinf o 

delivery 

M 

M 

M 

M 

N 

TypeofUA 

R/H 

H 

R 

M/G 

N 

NonDel iveredlnfo 

ReasonCode 

M 

M 

M 

M 

N 

DiagnosticCode 

H 

H 

H 

H 

N 

MOTIS-> 

UAprof ileldentif ier 

X 

N 

MOTIS-> 

UAprof ileldentif ier 

MOTIS-> 

ContentType 

M 

N 

MOTIS-> 

Encodedinf oTypes 

M 

N 

78 


Part  7:  1984  Message  Handling  Systems  December  1991  (Stable) 


Table  E.2  -  Protocol  Element  Comparison  of  Pi  (continued) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

P  r  obeEn  ve  1  ope 

probe 

M 

M 

M 

M 

N 

originator 

M 

M 

M 

M 

N 

Content Type 

M 

M 

M 

M 

N 

UAcontentID 

H 

H 

H 

H 

N 

originalEncInfoTypes 

G 

H 

H 

G 

Y  Conformance  (E) 

Tracelnformation 

M 

M 

M 

M 

N 

PerMessageFlag 

G 

G 

G 

G 

N 

ContentLength 

H 

H 

H 

H 

N 

PerDomainBilatlnfo 

X 

X 

X 

X 

N 

Recipientlnfo 

M 

M 

M 

M 

Y  TTC  256  max 

MOTIS->  InternalTracelnfo 

M/P 

P 

N 

•  • 

Recipientlnfo 

Rec i p i en t ORname 

M 

M 

M 

M 

N 

Extensionldentif ier 

M 

M 

M 

M 

N 

PerRecipientFlag 

M 

M 

M 

M 

N 

Expl i  c  i  tConver  s  i  on 

X 

X 

X 

X 

N 

MOTIS->  OriginReqAlternatRecip 

X 

N 

MOTIS->  Reassignmentlnfo 

X 

N 

PerRecipientFlag 

ResponsibilityFlag 

M 

M 

M 

M 

N 

ReportRequest 

M 

M 

M 

M 

N 

Us  e  r Repo  r  t  Reque  s  t 

M 

M 

M 

M 

N 

Tracelnformation 

GlobalDomainldent 

M 

M 

M 

M 

N 

DomainSuppliedlnfo 

M 

M 

M 

M 

N 
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Table  E.2  -  Protocol  Element  Comparison  of  PI  (concluded) 


PI  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

DomainSuppliedlnfo 

arrival 

M 

M 

M 

M 

N 

deferred 

X 

X 

X 

X 

N 

action 

M 

M 

M 

M 

N 

(0=relayed) 

G 

G 

G 

N  Note: 

Ke— routing  not 

required. 

( 1= rerouted ) 

n 

TT 

n 

TT 

n 

XT 

MOTIS->       ( 2=recipientReassigned) 

H 

N 

converted 

H 

G 

H 

H 

Y  Conformance (US) 

previous 

H 

G 

G 

X 

Y  Conformance (US) 

(Note:  G  is 

inconsistent  with 

action  (relayed) 

being  "H.") 

ORname 

Encodedinf ormat  ionTypes 

BitString 

M 

M 

M 

M 

N    See  Note  3 

G3NonBasicParameters 

X 

X 

X 

X 

N 

TeletexNonBasicParams 

X 

R 

X 

X 

Y  Conformance (US) 

PresentationAbilities 

X 

X 

X 

X 

N 

DeliveryReportMPDU 

G 

G 

M 

G 

N 

DeliveryReportEnvelop 

M 

M 

M 

M 

N 

DeliveryReportContent 

M 

M 

M 

M 

N 

DeliveryReportEnvelope 

report 

M 

M 

M 

M 

N 

-      -        originator  ORname 

M 

M 

M 

M 

N 

Traceinf ormat  ion 

M 

M 

M 

M 

N 

InternalTracelnfo 

M/P 

P 

N 
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Table  E.3  -  Protocol  Element  Comparison  of  P2 


XT  ^     IT  I.  \J  \^\J\^\J  X 

t\/  ^  X  X 

A/171  1 

t\/  ^  ^  X  X 

TTP 

X  X 

UAPDU 

IM  UAPDU 

G 

G 

G 

G 

N 

SR_UAPDU 

X 

X 

X 

X 

N 

IM_UAPDU 

Heading 

M 

M 

M 

M 

N 

Body 

M 

M 

M 

M 

N 

Heading 

IPmessagelD 

M 

M 

M 

M 

N 

Originator  ORname 

R 

R 

R 

M/G 

N 

Author izingUsers 

H 

H 

H 

H 

Y  TTC  16  max 

PrimaryRecipients 

G 

G 

G 

G 

y  TTC  256  max 

CopyRecipients 

G 

G 

G 

G 

Y  TTC  256  max 

BlindCopyRecipient 

H 

H 

H 

H 

Y  TTC  256  max 

InReplyTo 

G 

G 

G 

G 

N 

Obsoletes 

H 

H 

H 

H 

Y  TTC  8  max 

IT 

n 

IT 
XI 

IT 
XI 

IT 
XI 

X     X  X  \w>     O  UldA. 

Subject 

G 

G 

G 

G 

N 

ExpiryDate 

H 

H 

H 

H 

N 

ReplyBy 

H 

H 

H 

H 

N 

u 

XI 

XI 

XI 

u 

XI 

Importance 

H 

H 

H 

H 

N 

Sensitivity 

H 

H 

H 

H 

N 

Autoforwarded 

H 

H 

H 

H 

N 

MOTIS->  CirculationList 

X 

N 

MOTIS->  ObsoletingTime 

X 

N 

IPmessagelD 

ORname 

H 

H 

H 

H 

N 

Print ablest ring 

M 

M 

M 

M 

N 

ORdescr  iptor 

ORname 

H 

H 

H 

> 

N  See  Note  6 

FreeFormName 

H 

H 

H 

N 

Tel ephoneNumbe  r 

H 

H 

H 

G 

N 

Recipient 

ORdescriptor 

M 

M 

M 

M 

N 

ReportRequest 

X 

X 

X 

X 

N 

ReplyRequest 

H 

H 

H 

H 

N 
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Table  E.3  -  Protocol  Element  Comparison  of  P2  (continued) 


P2  Protocol 

NIST 

TV  /111 

A/311 

A/3211 

TTC 

PROBLEM  ( Y/N ) 

MOTIS->  CirculationList 

MOTIS— >  CircuiationMemDer 

X 

N 

MOTIS->  checkmark 

M 

N 

MOTIS->      member name 

M 

N 

MOTIS->  OBsoletingTime 

MOTIS->  Time 

H 

N 

MOTIS->  IP_MessageID 

H 

N 

1  Body 

BodyPart 

G 

M 

M 

G 

Y  Conformance  (US) 

SR_UAPDU 

NonReceipt  . 

H 

H 

H 

— 1 

_l 

N 

Receipt 

H 

H 

H 

N 

Reported 

M 

M 

M 

M 

N 

ActualRecipient 

R 

R 

R 

G 

N 

IntendedRecipient 

H 

H 

H 

H 

N 

Converted 

X 

X 

X 

G 

N 

MOTIS->  CirculationStatus 

X 

N 

NonReceipt Information 

Reason 

M 

M 

M 

M 

N 

NonReceiptQualif ier 

H 

H 

H 

H 

N 

=expired  (value) 

0 

0 

0 

0 

N 

— ODsoxetea  (vaiue; 

X 

± 

1 

X 

IN 

=subscriptionTerminated 

2 

2 

2 

2 

N 

MOTIS->      =timeobsoleted  (value) 

X 

N 

Comments 

H 

H 

H 

X 

N 

returned 

H 

X 

X 

X 

Y  Conformance  (E) 

Receiptlnformat ion 

Receipt 

M 

M 

M 

M 

N 

TypeOfReceipt 

H 

H 

H 

G 

N 

Supplementary Info 

X 

X 

X 

X 

N 
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Table  E.3  -  Protocol  Element  Comparison  of  P2  (concluded) 


P2  Protocol 

NIST 

A/311 

A/3211 

TTC 

PROBLEM  (Y/N) 

BODYPART  SUPPORT 

o  IA5  Text 

G 

G 

G 

N  See  Note  7 

O  TLX 

X 

X 

X 

N 

Y 

Y 

Y 

Vi 

O  G3FAX 

X 

X 

X 

N 

O  TIFO 

X 

X 

X 

N 

o  TTX 

X 

X/H 

X 

Y  Conf(US)See  Note  2 

o  VideoTex 

X 

X 

X 

N 

o  NationallyDef ined 

X 

X 

X 

N 

o  Encrypted 

X 

X 

X 

N 

o  ForwardedlPmessage 

H 

H 

H 

N 

o  SFD 

X 

X 

X 

N 

o  TIFI 

X 

X 

X 

N 

MOTIS->  o  ODA 

X 

N 

MOTIS->  o  IS06937  Text 

H 

N 

NOTES 

1  It  should  be  noted  that  the  A/311  profile  states:  For  routing  all  ADMDs  should  support  all  Form  1 
Variants  of  0/R  Name.  All  PRMDs  should  support  at  least  Form  1,  Variant  1  form  of  OR  Name. 

2  It  should  also  be  noted  that  the  A/311  profile  requires  that  all  ADMDs  should  support  the  reception  of 
Teletex  body  parts  for  delivery  to  their  own  UAEs. 

3  An  A/3211  implementation  may  generate  MOTIS  encoded  information  types.  See  6.11. 

4  Only  Form  1  Variant  i  of  0/Rname  shown  for  TTC,  but  TTC  defines  other  forms  and  variants.  Form  1 
Variant  1  recommended  for  PRMDs  and  ADMDs,  Form  1  Variant  2  also  recommended  for  ADMDs. 

5  DDA's  can  be  used  to  specify  recipients  in  any  Japanese  domains  other  than  TTC.  Assignment  of  DDAs 
for  UAs  within  TTC  domains  is  not  recommended. 

6  One  of  [Deliveredlnfo/NonDeliveredlnfo]  must  be  present.  TTC  encodes  this  as  shown.  Other  profiles 
represent  this  by  classifying  both  protocol  elements  as  generatable.  A  similar  situation  exists  with  the  P2 
ORdescriptor. 

7  TTC  is  expected  to  support  IA5  for  some  international  MHS  communications. 
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Annex  F  (informative) 


Interworking  Warnings 

ADMD  name  is  to  be  encoded  as  a  single  space  when  configurations  with  no  ADMD's  are  present.  It 
should  be  noted  that  this  may  change  in  January  1988  so  that  the  ADMD  name  is  encoded  as  a  zero 
length  element  in  such  cases. 

The  OSI  Implementors'  agreements  allow  implementation  to  generate  MPDUs  with  no  body  parts.  Such 
MPDUs  will  be  rejected  by  European-conformant  systems.  (Note  this  situation  may  change  in  January 
1988) 

In  order  to  optimize  the  number  of  recipients  you  can  read  and  reply  to,  it  is  advisable  to  be  able  to 
generate  all  standard  0/R  name  attributes. 
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Part  8:  Message  Handling  Systems 


December  1991  (Stable) 


Foreword 

The  text  in  this  chapter  contains  a  set  of  Message  Handling  System  (MHS)  Implementation  Agreements 
intended  to  serve  in  lieu  of  an  International  Standardized  Profile  (ISP)  for  MHS.  it  is  the  aim  of  the  OIW 
X.400  SIG  to  pursue  alignment  of  this  chapter  with  the  developing  ISP.  When  the  ISP  is  complete,  this 
chapter  will  be  revised  to  refer  to  the  ISP,  and  to  only  highlight  additional  practices  and  North  American 
regional  requirements. 
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Part  8  Message  Handling  Systems 


0  Introduction 

This  is  an  Implementation  Agreement  developed  by  the  Implementors'  Workshop  sponsored  by  the  U.  S. 
National  Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of  data  between  devices 
manufactured  by  different  vendors.  This  Agreement  is  based  on,  and  employs  protocols  developed  in  accord 
with,  the  OSI  Reference  Model.  It  provides  detailed  guidance  for  the  implementor  and  eliminates  ambiguities 
in  interpretations. 

This  is  an  Implementation  Agreement  for  Message  Handling  Systems  (MHS)  based  on  the  CCITT  X.400 
(1988)  series  of  Recommendations,  the  similar  (but  not  identical)  ISO  MOTIS  standard,  and 
Recommendations  F.435  and  X.435  (1991)  (see  References).  These  Recommendations  and  Standards  are 
referred  to  as  the  base  standards.  The  term  "MHS"  is  used  to  refer  to  both  sources  where  a  distinction  is 
unnecessary.  Similarly,  "1984"  and  "1988"  are  often  used  to  distinguish  between  the  CCITT  X.400  (1984) 
series  of  Recommendations  and  the  later  sources. 

This  Implementation  Agreement  seeks  to  establish  a  common  specification  which  is  conformant  with  both 
CCITT  and  ISO  with  a  view  to: 

a)  Preventing  a  proliferation  of  incompatible  communities  of  MHS  systems  which  are  isolated  for 
protocol  reasons; 

b)  Achieving  interworking  with  implementations  conforming  to  the  OIW  Stable  Implementation 
Agreements  for  CCITT  1984  X.400-based  Message  Handling  Systems;  and, 

c)  Facilitating  integration  of  other  OSI-based  services  (e.g.,  Directory)  within  a  single  real  system. 

This  Implementation  Agreement  is  designed  to  encourage  upgrade  of  existing  1984-based  systems  as 
follows: 

a)  To  add  1988  functionality  (Message  Store,  Remote  User  Agent,  etc.); 

b)  To  provide  additional  functionality  above  the  minimal  conformant  1988  MHS  defined  in  the 
December  1989  version  of  the  OIW  Implementation  Agreements.  These  1988  aspects  are  described 
in  this  Agreement  as  either  incremental  enhancements  or  new  functional  groups. 

However,  it  is  considered  that  the  OIW  Stable  Implementation  Agreements  for  CCITT  1984  X.400-based 
Message  Handling  Systems  (part  7)  should  not  be  withdrawn  at  this  stage.  It  is  anticipated  that  X.400  (1 984) 
implementations  will  continue  to  provide  a  viable  alternative  for  applications  that  do  not  require  the  additional 
1988  functionality  for  some  time. 
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1  Scope 

This  Agreement  specifies  the  requirements  for  MHS  implementations  based  on  the  1988  MHS  standards. 

This  Agreement  applies  equally  to  Private  Management  Domains  (PRMDs)  and  Administration  Management 
Domains  (ADMDs).  Four  boundary  interfaces  are  specified,  as  illustrated  in  figure  1: 

a)  Management  Domain  (MD)  to  MD; 

b)  Message  Transfer  Agent  (MTA)  to  MTA  within  a  domain; 

c)  MTA  to  remote  Message  Store  (MS)  or  User  Agent  (UA);  and, 

d)  MS  to  Remote  UA. 

MHS  protocols  other  than  the  Message  Transfer  Protocol  (P1),  the  Message  Transfer  System  Access 
Protocol  (P3),  the  Interpersonal  Messaging  Protocol  (P2),  and  the  Message  Store  Access  Protocol  (P7)  are 
beyond  the  scope  of  this  Agreement.  Issues  arising  from  the  use  of  other  protocols  are  outside  the  scope 
of  this  document.  This  Agreement  describes  the  services  provided  at  each  interface  shown  in  figure  1. 

MHS  implementations  may  be  configured  as  any  single  or  multiple  occurrence  or  combination  of  MTA,  MS 
and  UA,  as  illustrated  in  figure  1.  It  is  not  intended  to  restrict  the  types  of  system  that  may  be  configured 
for  conformance  to  this  Agreement  (although  it  is  equally  recognized  that  not  all  configuration  types  may 
be  commercially  viable). 


MD 


UA 


MTA 


UA 
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PI 


PI 
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MS  UA 


UA 
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Figure  1  -  Scenario  definition 

The  1988  MHS  standards  cover  a  wide  and  diverse  range  of  functional  areas,  not  all  of  which  would  be 
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relevant  to  every  implementation.  In  order  to  achieve  a  more  precise  definition  of  conformance  requirements 
according  to  the  functionality  supported  by  an  implementation,  and  additionally  to  facilitate  future 
enhancement  of  this  initial  specification,  the  concept  of  Functional  Groups  has  been  introduced. 
Conformance  requirements  for  support  of  Functional  Groups  by  particular  configurations  are  specified  in 
clause  17. 

In  the  context  of  these  agreements,  the  term  "Support"  means  that  the  service  provider  makes  the  element 
of  service  (and  related  elements  of  protocol)  available  to  the  service  user.  The  service  user  provides 
adequate  access  to  invoke  the  elements  of  service  and/or  makes  information  associated  with  the  sen/ice 
element  available.  Additionally,  for  "Not  Defined"  or  "Not  Applicable"  elements,  the  service  provider  is  not 
required  to  make  the  element  available  to  the  service  user.  However,  the  service  provider  should  not  regard 
the  occurrence  of  the  corresponding  protocol  elements  as  an  error  and  should  relay  those  elements. 
Naturally,  protocol  elements  marked  critical  for  submission,  transfer,  or  delivery  must  be  processed 
according  to  the  base  standards. 

The  following  functional  groups  are  covered  by  this  Implementors  Agreement: 

a)  The  MT  Kernel  in  clause  5; 

b)  The  Message  Store  in  clause  6; 

c)  Remote  User  Agent  support  in  clause  7; 

d)  Distribution  Lists  in  clause  8.3; 

e)  Use  of  Directory  in  clause  8.4; 

f)  Address  support  for  Teletex  character  sets  in  clause  8.5; 

g)  MHS  Management  in  clause  9  (which  is  for  further  study); 

h)  Security  in  clause  10; 

i)  The  Physical  Delivery  Access  Unit  in  clause  11.1; 

j)  Other  Access  Units  in  clause  1 1.2  (which  are  for  further  study); 
k)  Redirection  in  clause  12  (which  is  for  further  study);  and, 
I)  The  IPM  Service  in  clause  13; 

m)  The  EDI  Messaging  Service  in  clause  14  (which  is  for  further  study). 
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2.2  ISO 

Application  Layer  -  MHS 

ISO  10021-1  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  System  and  Service 
Overview. 

ISO  10021-2  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Overall  Architecture. 

ISO  10021-3  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Abstract  Service  Definition 
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ISO  10021-6  Information  Processing  Systems  -  Text  Communication  -  MOTIS  -  Protocol  Specifications. 

ISO  10021-7  Information  Processing  Systems  -  Text  Communication  -  t\AOTIS  -  Interpersonal  Messaging 
System. 


3  Status 

This  version  of  tine  Implementation  Agreements  for  Message  Handling  Systems  (MHS)  is  under  development. 
It  is  based  on  the  CCITT  X.400  (1988)  Recommendations  and  ISO  MOTIS  (10021,  parts  1-7)  standards,  as 
amended  by  the  MHS  Implementors  Guide,  version  6. 

The  initial  version  of  these  Stable  Implementation  Agreements  included  an  Agreement  which  specified  a 
minimal  1988-based  MHS  implementation  and  support  for  Message  Stores  and  Remote  User  Agents,  and 
which  addresses  interworking  with  1984-based  implementations.  This  version  of  the  Agreement  specifies 
support  for  several  additional  1988  features.  The  remaining  features  specified  in  the  1988  standards  will  be 
covered  in  subsequent  versions  of  this  Agreement. 

This  initial  version  has  not  yet  been  aligned  with  other  MHS  profiles,  so  changes  may  be  necessary  in  the 
future  for  international  harmonization,  e.g.,  support  for  international  character  repertoires  and  conversion. 


4  Errata 

No  Errata  to  Stable  material  at  this  time. 


5     MT  Kernel 


5.1  Introduction 

This  clause  specifies  the  requirements  for  a  minimal  1988-based  MTS  implementation  (i.e.,  MTA)  which  is 
capable  of  interworking  with  1984-based  MTAs.  The  "base"  MT  Service  specified  in  this  clause  does  not 
include: 

a)  Message  Store  (see  clause  6); 

b)  Remote  UA  (see  clause  7); 

c)  Distribution  Lists  (see  clause  8.3); 

d)  Use  of  Directory  Services  (see  clause  8.4); 

e)  Security  (see  clause  10); 
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f)  Interworking  with  Physical  Delivery  systems  or  Specialized  Access  (see  clause  11);  and, 

g)  Conversion  of  body  parts  (see  clause  13.6.2). 

Such  a  minimal  1988-based  MTA  will  have  the  following  capabilities  in  order  to  achieve  interworking  with 
1984-based  MTAs  and  to  facilitate  migration  to  full  1988  operation: 

a)  It  will  be  protocol-conformant  to  1988  PI; 


b)  It  will  downgrade  1988  PI  to  1984  PI  when  relaying  to  1984-based  MTAs,  as  specified  in  Annex 
B  of  X.419  (see  clause  5.5); 

c)  It  will  support  both  "normal"  mode  and  "X.410-1984"  ("passthrough")  mode  protocol  stacks  (i.e., 
as  required  by  ISO  and  CCITT  respectively);  and, 

d)  A  conforming  implementation  shall  obey  the  criticality  mechanism  defined  in  the  base  standards. 
The  following  abstract  operations  are  made  critical  for  delivery  for  these  Implementation 
Agreements:  message  token,  content  integrity  check,  and  content  confidentiality  algorithm  Id. 


5.2      Elements  of  Service 


This  clause  specifies  the  requirements  for  support  of  MT  Elements  of  Service  by  an  MTA  conforming  to  the 
MT  Kernel  Functional  Group  of  this  Agreement.  Table  1  specifies  the  support  for  the  basic  MT  Kernel 
elements  of  service  and  table  2  specifies  the  support  for  the  optional  MT  Kernel  elements  of  service. 

The  classification  scheme  for  support  of  Elements  of  Sen/ice  is  as  follows: 

Mandatory  (M):  the  Element  of  Service  must  be  supported  and  made  available  to  the  service  user; 

Optional  (0):  the  Element  of  Service  may  be  supported,  but  is  not  required  for  conformance  to  this 
Agreement; 

Out  of  Scope  (I):  the  Element  of  Service  is  outside  the  scope  of  these  Implementation  Agreements; 

Not  Applicable  (-):  the  Element  of  Service  is  not  applicable  in  the  particular  context  according  to 
the  base  standard;  and. 

To  Be  Determined  (*):  the  support  classification  for  the  Element  of  Service  has  yet  to  be 
determined. 

The  requirements  for  support  of  MT  Elements  of  Service  for  origination  and  reception  and  (where  relevant) 
relaying  are  distinguished.  Elements  of  Service  which  are  new  in  the  1988  MHS  standards  are  indicated  as 
(1988). 

An  MTA  must  support  those  Basic  MT  Elements  of  Service  and  MT  Optional  User  Facilities  defined  in  section 
19  of  X.400  (1988)  as  listed  and  qualified  in  tables  1  and  2. 

Specification  of  dynamic  behavior  in  these  agreements  will  only  be  included  In  those  cases  where  there  is 
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an  identified  functional  objective  whicfi  is  not  satisfied  by  tfie  specification  of  dynamic  beliavior  in  tlie 
corresponding  base  standard(s)  and  where  tlie  resulting  behiavior  does  not  breach  base  standard 
conformance  requirements. 

In  these  exceptional  cases,  there  may  be  situations  where  these  agreements  must  specify  the  dynamic 
behavior  of  an  implementation  as  distinguished  in  annex  C  of  ISO  TR-10  000.  Where  this  occurs,  a  table  of 
dynamic  conformance  requirements  will  be  presented  using  the  classification  scheme  below: 


Mandatory  (M):  The  element  must  be  implemented  although  use  is  not  required  for  conformance 
to  the  base  standard.  The  element  shall  always  be  used  for  conformance  to  these  agreements. 

Excluded  (X):  This  element  must  either  not  be  implemented,  or  it  must  be  possible  to  prevent  use 
of  the  element. 


NOTE  -  As  stated  in  clause  6.7  of  ISO  TR-10  000-1,  restrictions  by  a  profile  on  the  dynamic  conformance 
requirements  of  a  base  standard  are  exceptions,  and  should  only  apply  to  transmission.  Restrictions  should 
not  apply  to  reception.  In  the  case  of  Excluded  options,  it  must  be  possible  to  ensure  that  such  options  are 
not  initiated  or  transmitted.  However,  it  is  still  possible  that  an  implementation  may  receive  an  Excluded  element 
from  an  implementation  which  does  not  conform  to  the  same  profile. 


Table  1  -  MT  kernel:  basic  MT  elements  of  service 


Element  of  Service 

Origination 

Reception 

Relaying 

Access  Management 

Ml 

Ml 

Content  Type  Indication 

M 

M 

Converted  Indication 

M 

M 

M 

Delivery  Time  Stamp  Indication 

M 

Message  Identification 

M 

M 

Non-delivery  Notification 

M 

M 

M 

Original  Encoded  Information 

Types  Indication 

M 

M 

Submission  Time  Stamp  Indication 

M 

M 

User/UA  Capabilities 

Registration  (1988) 

Ml 

Notes 

1    A  local  matter  in  the  case  of  collocated  UA/MTA  and/or 
MS/MTA  configurations. 

7 


Part  8:  Message  Handling  Systems  December  1991  (Stable) 


Table  2  -  MT  kemei:  MT  service  Ootional  user  facilities 


Element  of  Service 

Origination 

Reception 

Relaying 

Alternate  Recipient  Allowed 

M 

m2 

_ 

Alternate  Recipient  Assignment 

- 

02 



Conversion  Prohibition 

M 

M 

M 

Conversion  Prohibition  in  Case 

of  Loss  of  Information  (1988) 

0 

0 

Deferred  Delivery 

M^ 

0 

0 

Deferred  Delivery  Cancellation 

m6 

_ 

_ 

Delivery  Notification 

M 

M 

_ 

Disclosure  of  Other  Recipients 

M 

M 

DL  Expansion  History  Indication 

M^ 

_ 

DL  Expansion  Prohibited 

_ 

_ 

Explicit  Conversion 

0 

0 

0 

Grade  of  Delivery  Selection 

M 

M 

Hold  for  Delivery 

- 

m1 

- 

Implicit  Conversion 

0 

0 

0 

Latest  Delivery  Designation  (1988 

0 

0 

0 

Multi  Destination  Delivery 

M 

M 

M 

Originator  Requested  Alternate 

Recipient  (1988) 

0 

0 

Notification 

M 

- 

Probe 

M 

M 

M 

Redirection  Disallowed  by 

Originator  (1988) 

M 

M 

— 

Redirection  of  Incoming 

Messages  (1988) 

0 

— 

Requested  Delivery  Method  (1988) 

M 

M 

- 

Restricted  Delivery  (1988) 

0 

- 

Return  of  Content 

0 

0 

0 

Notes 

1    A  local  matter  in  the  case  of  collocated  UA/MTA  and/or 

MS/MTA  configurations. 

2     If  Alternate  Recipient  Assignment  is  supported 

on 

reception,  then  support  of  Alternate  Recipient 

Allowed 

is 

Mandatory  on  reception;  otherwise,  support 

of  Alternate 

Recipient  Allowed  is  not  applicable  on  reception. 

3    Support  of  this  MT  Element  of  Service  is  Mandatory  for 

conformance  reasons,  but  may  be  performed  as  a 

local 

matter  to  the  originating  MTA. 

4     Support  of  this  MT  Element  of  Service  refers  only  to 

the 

delivery  of  DL  expansion  history  and  not  to  the  performing 

of  DL  expansion  (see  clause  8.3). 

5     Support  of  this  MT  Element  of  Service  does 

not 

imply 

the 

capability  to  perform  DL  expansion  (see  clause 

8.3)  . 

6    Messages  should  be  held  in  the 

originating 

MTA 

to  provide 

support  for  this  element  of  service. 
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5.3      MTS  Transfer  Protocol  (PI) 

The  requirements  for  support  of  MTS  Transfer  Protocol  (P1)  elements  are  detailed  in  clause  A.1. 
Support  of  MTS  Transfer  Protocol  application  contexts  by  an  MTA  is  classified  as  in  table  3. 


Table  3  -  Application  contexts  classification 


Application  Context 

Support 

mts-transf er-protocol-1984 
mts- transfer-protocol 
mts-transf er 

Mandatory 
Mandatory 
Mandatory 

Use  of  the  underlying  services  to  support  these  application  contexts  is  specified  in  clause  15. 


5.4      MTS  -  APDU  Size 

The  following  support  requirement  may  be  increased  in  the  future. 

NOTE  -  This  clause  is  for  further  study  by  the  OIW  X.400  SIG. 
The  following  agreements  govern  the  size  of  MTS-APDUs: 

a)  All  MTAEs  must  support  at  least  one  MTS-APDU  of  at  least  two  megabytes;  and, 

b)  The  size  of  the  largest  MTS-APDU  content  supported  by  a  UAE  is  a  local  matter. 


5.5      1988/84  Interworking  Considerations 

An  MTA  conforming  to  this  Agreement  will  downgrade  1988  PI  to  1984  PI  when  relaying  to  1984-based 
MTAs,  as  specified  in  Annex  B  of  X.419  with  the  following  additional  requirements: 

a)  Supplementary  Information  -  will  need  to  be  truncated  if  it  exceeds  the  pragmatic  constraint 
identified  in  Version  2  of  these  Agreements  (64  octets  as  opposed  to  256  octets  in  the  1988  MHS 
standards); 

b)  ISO  DIS  8883  Extensions  -  An  implementation  may  perform  the  mapping  of  ISO  DIS  8883 
extensions  to  existing  1988  services  when  relevant,  but  is  not  obliged  to.  Alternatively,  it  may  discard 
the  extensions  or  generate  a  non-delivery  report; 

c)  Internal  Trace  Information  -  If  the  1984-based  MTA  does  not  support  Internal  Trace  Information 
per  clause  7.3.2  of  part  7,  the  following  description  is  not  applicable.  When  a  1988-based  MTA 
supports  interworking  with  a  1984-based  MTA  that  generates  Internal  Trace  Information  as  per 
clause  7.3.3  of  part  7,  the  1988-based  MTA  must  support  reception  of  the  Internal  Trace  Information 
by  converting  the  Internal  Trace  Information  from  the  form  in  clause  7.3.2  of  part  7  to  the  form 
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specified  in  1 988  X.41 1 ,  as  per  the  following  description.  Winen  the  1 988-based  iVITA  sends  to  a  1 984 
MTA,  the  1 988-based  MTA  must  apply  the  conversion  to  1984,  as  described  below.  The  Stable  NBS 
Implementation  Agreements  X.400  (1984)  definition  for  MTA's  Internal  Trace  Information  is  different 
from  the  X.400  (1988)  MTA  definition.  Consequently,  a  X.400  (1988)  MTA  operating  in  an  MD  with 
other  MTAs  of  1984  vintage,  must  map  the  Internal  Trace  Information  to  and/or  from  the  1984 
format. 

Figures  2  and  3  depict  algorithms  for  mapping  between  X.400  (1988)  Internal  Trace  element  formats  and 
the  OIW  lA  X.400  (1984)  Internal  Trace  element  format. 

To  avoid  potential  looping  within  a  MD  composed  of  1984  and  1988  vintage  MTAs,  MD  administrators  are 
strongly  advised  to  name  all  MTAs  (1984  and  1988  vintages)  using  only  the  Printable  String  characters.  In 
X.400  (1988)  the  MTA-Name  is  defined  to  be  named  using  1A5  String  characters  where  in  the  lAs  for  X.400 
(1984)  MTAs,  NBS  restricted  the  MTA-Name  to  be  formed  using  the  Printable  String  character  subset  of  1A5. 
If  the  1 988-based  MTA  Name  uses  IA5  characters  not  in  the  Printable  String  subset,  that  Internal  Trace 
Element  should  be  omitted  when  converting  from  1988  to  1984. 


For  each  Internal  Trace  element  in  the  sequence: 
DO 

IF  MTA-Name  is  made  up  of  non-Printable  String  characters: 

Discard  this  Internal  Trace  element; 
ELSE 

{    Discard  the  GlobalDomainldentif ier ; 
Copy  the  MTAname  over; 
Within  the  MTASuppliedInf ormation: 
Copy  the  arrival  time  over; 
Copy  the  routing  action  over; 
IF  attempted  is  present 
{     IF  it  is  a  domain: 
Discard  it; 
IF  it  is  an  MTA: 
,  ^        Copy  it  to  Previous  MTAName; 

IF  the  additional  actions  are  present: 
{     IF  the  deferred  time  is  present: 
Copy  it  over; 
IF  the  other-actions  is  present: 
Discard  it; 


END-DO 


Figure  2  -  1988  to  1984  mapping 
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Find  the  [APPLICATION  30]  entry  in  the  PI  envelope; 
FOR  each  Internal  Trace  element: 
DO 

Insert  the  GlobalDomainldentif ier  of  this  MTA; 
Copy  the  MTAName  over; 
Within  the  MTASuppliedInf o: 
Copy  the  arrival  time; 
IF  the  deferred  time  is  present: 

copy  it  to  the  additional  actions  field  within  the 
1988  Internal  Trace  information; 
IF  the  routing  action  is  Relayed  or  Rerouted: 

copy  it  over; 
IF  the  routing  action  is  Recipient-reassigned: 

map  to  Relayed; 
IF  the  previous  MTAName  is  present: 

copy  it  to  the  MTAName  in  the  attempted  field; 


END-DO 


Figure  3  -  1984  to  1988  mapping 


6     Message  Store 


6.1  Introduction 


This  clause  specifies  Agreements  for  implementation  of  the  Message  Store  (MS)  Functional  Group.  The  MS 
is  responsible  for  accepting  delivery  of  messages  on  behalf  of  a  single  end-user,  and  retaining  the  messages 
until  the  end-user's  UA  is  able  to  retrieve  them.  Message  submission  and  some  administration  services  are 
provided  via  "pass-through"  to  the  MTS.  Figure  4  illustrates  the  logical  relationship  of  the  MS  to  the  UA  and 
MTS. 


UA 

RETRIEVAL 

MS 

DELIVERY 

-<  

INDIRECT 
SUBMISSION 

-<  

SUBMISSION 

 >- 

ADMINISTRATION 

ADMINISTRATION 

-<  >- 

-<  : 

MTS 


Figure  4  -  Message  store  model 


The  Agreements  in  this  clause  specify  the  Message  Store's  use  of  the  retrieval,  delivery,  and  administration 
services.  Agreements  on  submission  services  are  specified  in  clause  7,  which  describes  support  for  the 
Remote  UA. 


The  goal  of  the  Agreements  in  this  clause  is  to  define  the  minimal  set  of  features  which  are  necessary  to 
provide  useful  Message  Store  services,  independent  of  the  MTA  implementation  version  (i.e.,  1984  or  1988). 
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6.2  Scope 

The  scope  of  the  Agreements  in  this  clause  is  depicted  in  figure  5,  and  is  confined  to  the  sen/ices  and 
protocols  between  the  boundaries  shown  (marked  with  asterisks).  Requirements  for  the  UA  and  MTA  are 
addressed  only  to  the  extent  that  they  affect  the  Message  Store  and  Remote  User  Agent  sen/ices  and 
protocols.  This  reflects  the  additional  services  required  at  the  UA  to  support  MS  access  and  at  the  MTA  to 
support  a  remote  MS. 


* 

1 
1 

P7 

P3 

* 

1 
1 

UA 

MS 

MTA 

1 
1 

1 
1 

Figure  5  -  Scope  of  message  store  agreements 


The  UA,  MS  and  MTA  configuration  is  not  restricted;  any  of  these  components  may  be  collocated,  although 
they  are  depicted  as  logically  separate.  In  the  case  of  a  collocated  UA  and  MS,  a  proprietary  interface  may 
be  used  instead  of  P7.  In  the  case  of  a  collocated  MS  and  MTA,  a  proprietary  interface  may  be  used  instead 
of  P3. 


6.3      Elements  of  Service 

This  clause  specifies  the  requirements  for  support  of  Elements  of  Service  to  provide  a  Message  Store 
conforming  to  the  Message  Store  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 

Support  for  Elements  of  Service  is  specified  in  table  4  both  for  the  Message  Store  itself  and  for  the  User 
Agent. 


Table  4  -  Message  store:  elements  of  service 


Element  of  Service 

UA 

MS 

MS  Register 

0 

M 

Stored  Message  Deletion 

M 

M 

Stored  Message  Fetching 

M 

M 

Stored  Message  Listing 

M 

M 

Stored  Message  Summary 

M 

M 

Stored  Message  Alert 

0 

0 

Stored  Message  Auto  Forward 

0 

0 
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6.4  Attribute  Types 

Requirements  for  support  of  the  attributes  used  in  the  Message  Store  are  detailed  in  clauses  A.8  and  A.9. 
There  are  two  levels  of  support  for  General  Attributes  in  the  Message  Store. 

The  Basic  MS  is  intended  to  support  the  use  of  the  MS  as  a  continuously  available,  reliable  device  (such 
as  a  spooling  entity)  for  receiving,  storing,  and  forwarding  messages  and  reports.  The  Basic  MS  is  not 
required  to  support  any  content-specific  attributes. 

The  Enhanced  MS  supports  a  larger  number  of  general  attributes  and  is  suited  to  MSs  that  also  support 
content-specific  attritbutes. 

Additionally,  support  for  security  attributes  is  defined  in  clause  A.9,  for  use  in  secure  environments. 
Refer  to  the  content-specific  clauses  for  support  for  content-specific  attributes. 

6.5  Pragmatic  Constraints  for  Attribute  Types 

There  are  no  additional  pragmatic  constraints  for  attribute  types  beyond  those  of  the  base  standards. 

6.6  MS  Access  Protocol  (P7) 

The  requirements  for  support  of  MS  Access  Protocol  (P7)  elements  by  an  MS  and  a  remote  MS-user  are 
detailed  in  clause  A.4. 

The  requirements  for  support  of  MS  Access  Protocol  (P7)  application  contexts  by  an  MS  and  an  MS-user 
are  as  specified  in  clauses  6.1  and  10.1  of  X.419  (1988)  (ISO  10021-6)  with  the  additional  requirement  that 
an  MS-user  must  at  least  support  the  ms-access  application  context,  as  defined  in  table  5. 


Table  5  -  Application  contexts  support  for  P7 


Application  Context 

MS 

MS-user 

ms-access 

ms-reli able-access 

Mandatory 
Optional 

Mandatory 
Optional 

Use  of  the  underlying  sery/ices  to  support  these  application  contexts  is  specified  in  clause  15. 
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6.7      MTS  Access  Protocol  (P3) 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  elements  by  an  MTA  and  an  MS  where  the  MS 
is  not  collocated  with  the  MTA  are  detailed  in  clause  A.3. 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  application  contexts  by  an  MTA  and  an  MS  in 
such  a  scenario  are  as  specified  in  sections  6.1  and  10.1  of  X.419  (1988)  (ISO  10021-6)  with  the  additional 
requirement  that  a  remote  MS  must  at  least  support  the  mts-access  and  mts-forced-access  application 
contexts,  as  defined  in  table  6. 


Table  6  -  Application  contexts  support  for  P3 


Application  Context 

MTA 

MS 

mts-access 

mts-forced-access 

mts -reliable-access 

mts -forced-reliable-access 

Mandatory- 
Mandatory 
Optional 
Optional 

Mandatory 
Mandatory 
Optional 
Optional 

Use  of  the  underlying  services  to  support  these  application  contexts  is  specified  in  clause  15. 


7     Remote  User  Agent  Support 


7.1  Introduction 

This  clause  specifies  Agreements  for  implementation  of  the  Remote  User  Agent  Functional  Group,  i.e.,  for 
support  of  an  UA  that  is  not  collocated  with  its  MTA. 

The  goal  of  the  Agreements  in  this  clause  is  to  define  the  minimal  set  of  features  which  are  necessary  to 
provide  useful  Remote  User  Agent  services,  independent  of  the  MTA  implementation  version  (i.e.,  1984  or 
1988),  and  independent  of  any  particular  content  type.  The  content-specific  requirements  for  UAs  are 
specified  in  the  content-specific  sections  of  this  part  of  the  Implementor's  Agreements. 


7.2  Scope 

The  scope  of  the  Agreements  in  this  clause  is  depicted  in  figure  6,  and  Is  confined  to  the  services  and 
protocols  between  the  boundaries  shown  (marked  with  asterisks).  Requirements  for  the  UA  and  MTA  are 
addressed  only  to  the  extent  that  they  affect  the  Remote  User  Agent  services  and  protocols.  Access  to  a 
Message  Store  by  a  Remote  User  Agent  is  covered  in  clause  6. 
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* 
1 

1 

P3 

j 

UA 

MTA 

Figure  6  -  Scope  of  remote  user  agent  agreements 


7.3      Elements  of  Service 

This  clause  specifies  tlie  requirements  for  support  of  Elements  of  Service  for  conformance  to  the  Remote 
User  Agent  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 

Support  for  Elements  of  Service  is  specified  for  the  MT  Service  (table  7)  and  is  in  addition  to  the  support 
requirements  specified  in  clauses  5  and  13  if  this  Functional  Group  is  supported. 


Table  7  -  Remote  user  agent  support:  MT  elements  of  service 


Element  of  Service 

Origination 

Reception 

Access  Management 

M 

M 

Hold  for  Delivery 

M 

User/UA  Capabilities  Registration 

M 

7.4      MTS  Access  Protocol  (P3) 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  elements  by  an  MTA  and  an  MTS-user  (whether 
UA  or  UA/MS)  where  the  MTS-user  is  not  collocated  with  the  MTA  are  detailed  in  clause  A.3. 

The  requirements  for  support  of  MTS  Access  Protocol  (P3)  application  contexts  by  an  MTA  and  an  MTS-user 
in  such  a  scenario  are  as  specified  in  sections  6.1  and  10.1  of  X.419  (1988)  (ISO  10021-6)  with  the 
additional  requirement  that  a  remote  MTS-user  must  at  least  support  the  mts-access  and  mts-forced-access 
application  contexts,  as  defined  in  table  8. 


Table  8  -  Application  contexts  support  for  P3 


Application  Context 

MTA 

MTS-user 

mts-access 

mts-forced-access 

mts-reli able-access 

mts -forced-reliable-access 

Mandatory 
Mandatory 
Optional 
Optional 

Mandatory 
Mandatory 
Optional 
Optional 
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Use  of  the  underlying  services  to  support  these  application  contexts  is  specified  in  clause  15. 


8     Naming,  Addressing  &  Routing 


8.1      Use  of  O/R  Addresses  for  Routing 

Procurers  are  responsible  for  understanding  the  implications  of  routing  requirements  and  capabilities. 


8.2      ORAddress  Attribute  List  Equivalence  Rules 

Two  ORAddresses  are  equivalent  if  each  contains  the  same  set  of  attributes  and  each  attribute  compares 
in  type  and  value. 

The  following  equivalence  rules  apply  when  comparing  a  provided  ORAddress  with  a  collection  of  known 
ORAddresses.  For  example,  in  order  to  perform  delivery  of  a  message  to  a  recipient,  the  MTA  must 
unambiguously  match  the  ORAddress  contained  in  the  message  with  the  known  ORAddresses.  See  X.402 
(1988),  section  18.4,  for  the  base  standard  attribute  equivalence  rules.  The  following  additional  rules  must 
also  be  applied  by  the  delivering  (or  non-delivering)  MTA: 

a)  If  the  provided  ORAddress  is  an  unambiguous  underspecification  of  a  known  ORAddress,  the 
ORAddresses  are  equivalent.  For  example,  if  the  initials  were  omitted,  the  ORAddress  would  still  be 
equivalent.  Under-specification  means  that  some  attributes  that  are  not  present  in  the  provided 
ORAddress  are  present  in  the  known  ORAddresses.  Under-specification  does  not  mean  partial  value 
(e.g.,  substring)  equivalence  when  the  same  set  of  attributes  are  present  in  the  ORAddresses. 

b)  Over-specified  ORAddresses  are  not  equivalent.  Over-specification  means  that  more  attributes 
are  present  in  the  provided  ORAddress  than  are  present  in  the  known  ORAddresses. 

c)  An  ADMD  or  PRMD  name  that  is  all  numeric  but  encoded  as  Printable  String  is  considered  to 
if        be  equivalent  to  the  same  ADMD  or  PRMD  name,  respectively,  with  the  same  numeric  values 

encoded  as  Numeric  String. 

NOTES 

,:  ;    1  An  X.500  Directory  service  may  or  may  not  support  these  matching  rules  for  equivalence. 
2  Operational  equivalence  between  T.61  and  Printable  String  is  for  further  study. 
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8.3.1  Introduction 

This  clause  identifies  and  specifies  tlie  Distribution  Lists  Functional  Group,  which  covers  ail  issues  relating 
to  the  performance  of  distribution  list  (DL)  expansion  by  an  MTA.  Other  aspects  concerned  with  the  use  of 
distribution  lists  are  covered  in  the  MT  Kernel  Functional  Group. 


8.3.2       Elements  of  Service 

This  clause  specifies  the  requirements  for  support  of  Elements  of  Service  for  conformance  to  the  Distribution 
Lists  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 

Support  for  Elements  of  Service  is  specified  for  the  MT  Service  only  (table  9),  and  is  only  concerned  with 
the  performance  of  DL  expansion  by  an  MTA.  Such  support  is  in  addition  to  the  support  requirements 
specified  in  clause  5  if  this  Functional  Group  is  supported. 


Table  9  -  Distribution  lists:  MT  elements  of  service 


Element  of  Service 

Support 

DL  Expansion  History  Indication 
DL  Expansion  Prohibited 
Use  of  Distribution  List 

M 
M 
Ml 

Notes 

1    Use  of  distribution  list  names  is 
always  possible,  as  they  have  no 
special  requirements  on  0/R  Names. 

8.4      MHS  Use  of  Directory 


8.4.1  Introduction 

The  MHS  standards  recognize  the  need  of  MHS  users  for  a  number  of  directory  service  elements.  Directory 
service  elements  are  intended  to  assist  users,  their  UAs,  and  MTAs  in  obtaining  information  for  use  in 
submission,  delivery,  and  the  transfer  of  messages. 

NOTE  -  The  MIS  may  also  use  the  directory  service  elements  to  obtain  information,  for  example,  to  be  used 
in  the  routing  of  messages.  This  application  of  the  directory  service  is  not  defined  by  the  base  standards  and 
is  therefore  not  addressed  by  this  Agreement. 
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8.4.2 


Functional  Configuration 


Two  MHS  functional  entities,  the  UA  and  MTA,  may  access  the  Directory  service  using  the  Directory  User 
Agent  (DUA).  The  interface  between  the  UA  and  DUA,  or  MTA  and  DUA  Is  local  and  not  defined.  The 
interaction  between  the  DUA  and  Directory  System  Agent  (DSA)  is  specified  in  part  1 1 .  A  collocated  DUA 
and  DSA  is  also  permitted. 


8.4.3  Functionality 

Examples  of  functional  usages  of  directories  have  been  identified  for  UAs  and  the  MTAs  in  conjunction  with 
their  DUAs.  These  are: 

a)  UA  Specific  Functionality: 


1 )  Verify  the  existence  of  a  Directory  Name; 

2)  Given  a  partial  name,  return  a  list  of  possibilities; 

3)  Search  the  Directory  for  entries  containing  a  specified  attribute  type  and  value  and 
return  the  Distinguished  Names  of  the  matching  entries; 

4)  Return  the  0/R  Address(es)  that  correspond  to  a  Directory  Name; 

5)  Determine  whether  a  Directory  Name  presented  denotes  a  user  or  a  Distribution  List; 

6)  Return  the  members  of  a  Distribution  List; 

7)  Return  the  capabilities  of  the  entity  referred  to  by  a  Directory  Name; 

8)  Maintenance  functions  to  keep  the  directory  up-to-date,  e.g.,  register  and  change 


credentials, 
b)  MTA  Specific  Functionality: 
'  ■  1)  Authentication; 

2)  Return  the  0/R  Address(es)  that  correspond  to  a  Directory  Name; 

3)  Determine  whether  a  Directory  Name  presented  denotes  a  user  or  a  Distribution  List; 

4)  Return  the  members  of  a  Distribution  List; 

5)  Return  the  capabilities  of  the  entity  referred  to  by  a  Directory  Name; 

6)  Maintenance  functions  to  keep  the  directory  up-to-date. 

In  addition  to  functionality,  a  number  of  operational  aspects  must  be  considered.  These  include 
user-friendliness,  flexibility,  availability,  expandability  and  reliability. 
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8.4.4       Naming  and  Attributes 

Since  user-friendliness  is  of  primary  importance  in  a  messaging  system,  the  naming  conventions  used  in 
building  the  Directory  Information  Tree  (DIT)  will  impact  the  ability  of  a  user  to  make  intelligent  guesses  for 
Directory  Names. 

It  is  recommended  that  the  naming  guidelines  and  DIT  structures  defined  in  Annex  B  of  Recommendation 
X.521  /ISO  9594-7  be  used  as  the  basis  for  MHS  Directory  Names.  Annex  C  of  Recommendation  X.402/ISO 
10021-2  specifies  further  the  MHS  specific  object  classes.  The  naming  for  MHS  specific  object  classes  are 
recommended  as  follows: 

a)  The  naming  for  mhs-message-store,  mhs-message-transfer-agent,  and  mhs-user-agent  is  that 
of  Application  Entity  in  the  DIT; 

b)  The  naming  attribute  for  mhs-distribution-list  is  commonName.  The  organization, 
organizational  Unit,  organizationalRole,  organizationalPerson,  locality,  or  groupOf  Names  can  be 
immediate  superior  to  entries  of  object  class  mhs-distribution-list; 

c)  The  naming  for  mhs-user  is  that  of  organizationalPerson,  residential  Person,  organizationalRole, 
organizationalUnit,  organization,  or  locality. 

NOTE  -  The  mhs-user  object  clacs  is  a  generic  object  class  which  may  be  used  in  conjunction  with  another 
standard  object  class  for  the  purpose  of  adding  MHS  information  attributes,  such  as  ORAddresses,  to  a 
Directory  entry.  The  means  to  associate  attributes  of  a  generic  object  class  to  an  entry  (or  to  different  entries) 
named  by  a  standard  object  class(es)  is  by  defining  a  new  (un-) registered  object  class,  whose  superclass(es) 
is  that  of  the  naming  object  class(es),  and  of  the  generic  object  class.  E.g.,  to  associate  mhs-user  attributes 
in  the  organizationalPerson  entry,  a  new  unregistered  object  class  can  be  defined  as  shown  in  figure  7. 


real-user-entry     ::=    OBJECT  CLASS 

SUBCLASS  OF  organizationalPerson, 
mhs-user 


Figure  7  -  Example  of  unregistered  object  class  definition 

The  MHS  object  classes,  attributes,  and  attribute  syntaxes  that  need  to  be  supported  by  the  Directory  are 
as  specified  in  Annex  C  of  Recommendation  X.402/ISO  10021-2. 

In  addition,  the  object  classes  organization,  organizationalUnit,  organizationalRole,  organizationalPerson, 
locality,  groupOfNames,  residentialPerson,  and  country  and  their  attributes  and  associated  syntaxes  as 
defined  in  X.520  (ISO  9594,  Part  6)  and  X.521  (ISO  9594,  Part  7)  are  required  to  support  the  MHS. 
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8.4.5       Elements  of  Service 

This  clause  specifies  the  requirements  for  support  of  Elements  of  Service  for  conformance  to  the  Use  of 
Directory  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 
Support  for  Elements  of  Service  is  specified  both  for  the  MT  Service  (table  10). 


Table  10  -  Use  of  directory:  MT  elements  of  service 


Element  of  Service 

Origination 

Reception 

Relay 

Designation  of  Recipient  by 
Directory  Name 

M 

M 

8.4.6       Directory  Services 

These  Implementation  Agreements  require  the  Directory  services  as  defined  in  table  11.  Indicated  are  the 
Directory  services  required  to  support  the  needs  of  the  MHS  UA/MTA  and  MHS  Administrator. 


Table  11  -  Directory  service  support  requirements 


Directory  Service 

MHS 
UA/MTA 

MHS 
Admin 

Bind  and  Unbind 

M 

M 

Read 

M 

M 

Compare 

M 

M 

Abandon 

M 

M 

List 

M 

M 

Search 

M 

M 

Add  Entry 

0 

M 

Remove  Entry 

0 

M 

Modify  Entry 

M 

0 

Modify  RDN 

0 

0 

8.4.7       OIW  X.400  Base  Directory  Implementation  Agreements 

This  clause  defines  the  X.400  base  Directory  Implementation  Agreements.  Its  structure  and  content  are 
based  on  the  Implementation  Agreements  template  suggested  in  part  11. 

8.4.7.1         Other  Profiles  Supported 

The  OIW  X.400  Base  Directory  Implementation  Agreements  requires  the  support  of  OIW  Directory  Common 
Application  Directory  Implementation  Agreements  as  defined  in  part  11. 


20 


Part  8:  Message  Handling  Systems  December  1991  (Stable) 

8.4.7.2         Standard  Application  Specific  Attributes  and  Attribute  Sets 

The  standard  application  specific  attributes  and  attributes  sets  supported  by  these  Implementation 
Agreements  are  listed  in  table  12.  For  each  attribute  and  attribute  set,  a  reference  is  provided  to  the  standard 
where  it  is  defined. 


Table  12  -  Standard  attributes  and  attribute  sets 


Attribute  /  Attribute  Set 

References 

mhs-deliver able-content-length 

mhs-deliver able-content -types 

mhs-deliverable-eits 

mhs-dl -members 

mhs-dl-submit-permissions 

mhs-mes sage-store 

mhs-or-addr esses 

mhs-prefer red-deli very-methods 

mhs-supported-automatic-actions 

mhs-supported-content -types 

mhs-supported-optional-at tributes 

X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 

8.4,7.3         Standard  Application  Specific  Object  Classes 

The  standard  application  specific  object  classes  supported  by  these  Implementation  Agreements  are  listed 
in  table  13.  For  each  object  class,  a  reference  is  provided  to  the  standard  where  it  is  defined. 


Table  13  -  Standard  object  classes 


Object  Class 

References 

mhs-distribut ion-list 
mhs-mes sage-store 
mhs-message-transf er-agent 
mhs-user 
mhs-user-agent 

X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 
X.402/IS  10021-2 

8.4.7.4  OIW  Application  Specific  Attributes  and  Attribute  Sets 

There  are  no  application  specific  attributes  or  attribute  sets  defined  by  these  Implementation  Agreements. 

8.4.7.5  OIW  Application  Specific  Object  Classes 

There  are  no  application  specific  object  classes  defined  by  these  Implementation  Agreements. 
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8.4.7.6 


Structure  Rules 


This  clause  defines  the  naming  and  structure  rules  for  the  MHS  object  classes  which  are  subclasses  of  top. 


Attribute  commonName  is  used  for  naming. 

The  mhs-distribution-list,  organization,  organizationalUnit,  organizationalRole,  organizationalPerson,  locality, 
or  groupOfNames  can  be  immediately  superior  to  entries  of  object  class  mhs-distribution-list. 


The  naming  for  mhs-user  is  that  of  organizationalPerson,  residentialPerson,  organizationalRole, 
organizationalUnit,  organization,  or  locality. 

The  organizationalPerson,  residentialPerson,  organizationalRole,  organizationalUnit,  organization,  or  locality 
object  classes  can  be  combined  with  the  mhs-user  object  class  to  form  a  new  composite  object  class. 
Use  of  Capabilities  Information 

The  capabilities  information  in  the  X.500  Directory  should  not  be  considered  sufficient  to  warrant  a  non- 
delivery decision  by  an  originating  or  relaying  MTA.  This  clause  is  not  intended  to  impose  any  conformance 
requirement. 


8.5      Address  Support  for  Teletex  Character  Sets 

This  clause  identifies  the  Address  Support  for  Teletex  Character  Sets  Functional  Group,  which  covers  the 
generation  of  Teletex  strings  in  OR  Address  components. 

Support  of  this  functional  group  Implies  that,  if  an  address  component  is  supported  for  origination,  the 
corresponding  Teletex  component  (if  any)  must  be  supported  for  origination. 


8.6      Reply  Support 

When  originating  a  reply,  the  UA  must  be  able  to  utilize  the  applicable  addressing  components  of  the 
message  to  which  it  is  replying  (regardless  of  character  set  support  level). 


8.4.7.6.1 


MHS  Distribution  List 


8.4.7.6.2 


MHS  User 
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9 


MHS  Management 


NOTE  -  For  further  study. 


10 


MHS  Security 


10.1 


Overview 


The  Security  functional  group  is  specified  as  three  security  classes  which  are  incremental  subsets  of  the 
security  features  available  in  the  base  standard.  They  are  denoted  as  SO,  S1 ,  and  S2.  An  implennentation 
that  conforms  to  the  Security  functional  group  map  support  one  or  more  of  the  security  classes  defined  In 
these  Implementation  Agreements. 

SO:  This  security  class  gathers  together  security  functions  applicable  only  between  MTS-Users. 
Consequently,  security  mechanisms  are  implemented  within  the  MTS-User.  An  MTA  is  required  to  support 
the  syntax  of  the  security  services  on  submission,  as  the  "Kernel"  supports  the  syntax  on  relay  and  delivery. 
The  MTA  is  not  expected  to  understand  the  semantics  of  the  security  services. 

S1:  This  security  class  requires  secure  functionality  with  the  MTS-User  and  MTS.  The  MTS  secure 
functionality  is  only  required  to  achieve  secure  access  management.  As  with  SO,  most  of  the  security 
mechanisms  are  implemented  within  an  MTS-User.  It  primarily  provides  integrity  and  authentication  between 
MTS-Users.  However,  MTAs  are  expected  to  support  digital  signatures  for  peer  to  peer  authentication, 
security  labelling  and  security  contexts. 

S2:  This  security  class  is  a  superset  of  S1 ,  adding  security  functions  within  MTAs  and  the  MTS.  The  main 
security  function  added  within  this  group  is  authentication  within  the  MTS,  and,  as  a  consequence,  due  to 
the  non-repudiable  nature  of  the  keys  used  for  authentication,  non-repudiation  is  also  added. 

In  addition,  each  of  the  three  security  classes  has  a  variant,  denoted  as  SOa,  S1a,  and  S2a,  which  mandates 
support  of  end-to-end  confidentiality. 

Symmetric  or  asymmetric  techniques  (or  a  combination  thereof)  may  be  used  within  each  security  class  and 
are  identified  by  the  registered  algorithm  identifier. 

Various  levels  of  assurance  in  trusted  COMPUSEC  functionality  may  be  used  within  each  security  class.  This 
is  outside  the  scope  of  this  Implementors  Agreement. 

A  full  rationale  for  each  of  the  security  classes  and  a  broader  discussion  of  security  considerations  are 
provided  in  annex  E. 

Table  14  provides  an  overview  of  the  requirements  made  by  the  security  classes  on  the  MTS-User  and  MTA. 
The  table  entries  are  descriptive,  and  are  not  intended  to  refer  to  security  service  elements. 
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Table  14  -  Overview  of  security  requirements  for  each  security  class. 


Requirements 

MTS-User 

MTA 

Kernel 

Submission,  delivery,  and 
relay  of  EoS 

DU 

Content  Integrity,  Proof  of 
Delivery,  Message  Origin 
Authentication  (UA  to  UA) 

Kernel 

SOa 

SO  plus  Content 
Conf  i  dent  i  al i  ty 

Kernel 

SI 

SO  plus  Message  security 
label.  Message  security 
context.  Security  Management 
Ser vi  cps 

Peer  entity  authentication. 
Security  context,  Security 
Management  Services,  and 
Messaae  Securitv  Label 

Sla 

SI  plus  Content 
confidentiality 

SI 

S2 

SI  plus  Message  Origin 
Authentication  Check,  Probe 
Origin  Authentication  Check, 
Report  Origin  Authentication 
Check,  Proof  of  Submission, 
and,  Non- repudiation 

SI  plus  Message  Origin 
Authentication  Check,  Prove 
Origin  Authentication  Check, 
Report  Origin  Authentication 
Check,  Proof  of  Submission, 
and.  Non-repudiation 

S2a 

Sla  plus  S2 

Sla  plus  S2 

The  incremental  functionality  of  the  security  classes  can  be  represented  diagrammatically  as  shown  in  figure 
8. 


SO 

1 
1 

\ 

1 
1 

SOa 

SI 

1 
1 

\ 

1 
1 

Sla 

S2 

\ 

S2a 

Figure  8  -  Incremental  functionality  of  the  security  classes 
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10.2.1      Interworking  Between  Security  Classes 

A  security  class  can  be  viewed  as  a  tool  which  can  be  used  to  implement  a  security  policy,  and  is  not  a 
security  policy  in  its  own  right  but  a  component  of  a  security  policy. 

Interworking  between  implementations  supporting  different  security  classes  can  be  achieved  in  terms  of  any 
common  class(es)  supported.  As  specified  in  the  base  standard,  the  label  of  the  message,  probe  or  report 
must  be  checked  against  the  security  context  by  any  implementation  claiming  conformance  to  classes  SI, 
Sla,  S2,  and  S2a. 

NOTE  -  Interworking  can  be  limited  to  messages  of  only  one  security  class  by  defining  a  security  context 
consisting  of  labels  with  security  policy  identifiers  of  only  that  security  class. 

This  profile  defines  security  policy  identifiers  (annex  B,  figure  18)  that  corresponds  to  the  security  classes 
defined  in  this  section.  Such  generic  security  policy  identifiers  only  imply  support  of  the  X.400  security 
services  as  specified  for  these  security  classes  in  this  clause.  No  other  COMSEC  or  COMPUSEC 
functionality  can  be  assumed  by  use  of  such  policy  identifiers.  More  specific  security  policies  may  be  based 
on  one  or  more  of  the  security  classes  in  this  section  but  will  require  use  of  registered  policy  identifiers. 


10.2.2      Comparison  of  Security  Labels 

The  Security  Content  service  ensures  that  the  message  security  label  matches  at  least  one  of  the  set  of 
labels  specified  in  the  security  content  established  between  the  communicating  MHS  entities. 

An  MTA  which  supports  the  Security  Content  service  shall  as  a  minimum  support  matching  for  equality  on 
the  security-policy-identifier,  security-classification,  and  security-categories  elements  of  the  label. 

NOTE  -  The  basic  support  requirement  is  that  absence  of  an  element  shall  not  be  treated  as  "any  value,"  i.e., 
all  permissible  combinations  of  occurrence  and  value  for  the  elements  of  the  message  security  label  must  be 
elaborated  in  the  security  context. 

Any  other  matching  rules  (e.g.,  covering  the  privacy-mark  element  or  based  on  alternative  methods  of 
comparison  may  be  used  in  particular  application  scenarios,  but  such  specification  and  usage  will  be  subject 
to  bilateral  agreement  and  will  depend  on  the  security  policy  in  force. 

The  message  security  label  can  be  placed  in  the  per-message  extensions  or  in  the  signed  or  encrypted  data 
of  the  per-recipient  message  token.  It  is  recommended  that  the  integrity  of  the  security  label  is  protected 
by  including  it  in  the  token  signed  data,  or  (if  the  label  is  in  the  per-message  extensions)  by  computing  the 
message  origin  authentication  check  on  the  message.  (Support  of  MOAC  is  optional  in  security  classes  SO 
and  Si.)  Which  of  these  labels  is/are  checked  by  the  security  context  service  is  dictated  by  the  security 
policy  in  force.  The  security  policy  should  also  define  any  requirements  on  allowable  (per-recipient)  label 
values  in  the  case  where  the  message  is  addressed  to  multiple  recipients  (and  thus  has  multiple  tokens). 

A  label  may  also  be  included  In  the  token  encrypted  data  with  (confidential)  end-to-end  semantics. 
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10.2.3      Application  Context 

When  providing  tlie  peer  entity  authentication  service,  it  is  recommended  that  MTAs  should  not  use  the 
"association-recovery"  procedure  of  RISE  (section  7.8.3  of  X.228).  MTAs  in  the  role  of  sender  should  not 
invoke  this  procedure  and  MTAs  in  the  role  of  receiver  should  not  accept  RT-OPEN  requests  asking  for 
recovery. 

NOTE  -  It  Is  permissible  for  the  sending  MIA  to  perform  the  "activity  resumption"  (sec.  7.8.1  of  X.228)  on  an 
existing,  authenticated  RISE  association  owned  by  this  MIA. 


10.3    Description  of  Security  Classes 

The  sections  to  follow  describe  the  security  classes  within  the  Security  functional  group.  For  each  security 
class,  there  is  a  description  of  the  security  functionalities  provided,  followed  by  a  table  which  gives  the 
classification  for  each  of  the  security  services  required  by  that  class.  Where  the  classification  of  a  security 
service  does  not  change  for  a  higher  security  class,  then  that  security  service  is  not  repeated  in  the  table 
for  the  higher  security  class. 

Figure  9  explains  the  column  headings  used  in  the  security  class  tables.  The  classifications  are  defined  in 
clause  5.2. 


1—1- 


UA 


8- 


MS 


MTA 


MTA 


MS 


UA 


Legend 

1:  UA/UA  4:  UA/MTA 

2:  UA/MS  5:  MTA/MS 

3:  MS /MTA  6:  MTA/MTA 


7:  MTA/UA 

8:  MS/Originating  UA 
9:  MS/Recipient  UA 


Figure  9  -  Security  interfaces 
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10.4    Security  Class  0  (SO) 

10.4.1  Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  implementation  in  order  to  provide  the  following: 

a)  Integrity  of  message  content; 

b)  Authentication  of  the  MTS-User  who  originated  the  message; 

c)  Authentication  of  the  MTS-User  to  whom  the  message  was  delivered. 
This  security  class  mandates  the  above  services  are  provided  by  an  MTS-User. 
There  are  no  requirements  placed  on  the  MTA. 

10.4.2  Security  Services  for  SO 

Security  class  0  (SO)  mandates  the  security  sen/ices  listed  in  table  15. 
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Table  15  -  Security  class  0  (SO) 


Security  Interface 

1 
UA/ 
UA 

2 

UA/ 
MS 

3 

MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 

MS/ 
UA 

9 

MS/ 
UA 

Security  Service 

Origin  Authentication 

Message  Origin  Authentication-'- 
Probe  Origin  Authentication 
Report  Origin  Authentication 
Proof  of  Submission 
Proof  of  Delivery 

M 
M 

Is 

I 

I 

I 

I 

I 
I 

M^ 

- 

Secure  Access  Management 

Peer  Entity  Authentication^'' 
Security  Context 

0 
0 

0 
0 

0 
0 

0 

0 

0 
0 

0 
0 

0 
0 

Data  Confidentiality 

Connection  Conf identiality° 
Content  Confidentiality 
Message  Flow  Confidentiality 

I 
I 

I 

I 

I 

I 

I 

I 

- 

I 

Data  Integrity  Services 
Connection  Integrity" 
Content  Integrity 
Message  Sequence  Integrity^^ 

M 
0 

1 

I 

I 

I 

I 

I 

I 

Non-Repudiation 

Non— Repudiat ion  of  Origin  ' 
Non-Repudiation  of  Submission 
Non-Repudiation  of  Delivery^ ' ■'■'^ 

r\ 
U 

0 

T 
1 

I 

0 

Message  Security  Labelling^ 

0 

0 

0 

0 

0 

0 

0 

0 

0 

Security  Management  Services 
Change  Credentials 
Register 
MS-Register 

0 
0 
0 

0 
0 

0 

l9 

0 
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Table  15  -  Security  class  0  (SO)  (concluded) 


Notes 

1  Only  provided  to  the  message  recipient. 

2  Using  either  symmetric  or  asymmetric  algorithms  as  identified 
by  the  algorithm  identifier  in  the  applicable  protocol  element. 

3  When  security  labelling  is  used,  the  security  policy  identifier  shall 
be  included. 

4  If  Proof  of  Delivery  and  Content  Confidentiality  are  both  used,  and 
delivery  is  to  an  MS,  then  proof  of  delivery  can  only  be  computed  on  the 
encrypted  content.  It  should  be  noted  that  this  will  not  provide 
non-repudiation  of  delivery. 

5  Using  either  a  trusted  notary  (syinmetric)  or  using  certificates 
tokens  which  are  not  repudiable  (asymmetric). 

6  Corrects  table  7  of  X.402  in  the  base  standard. 

7  Authentication  between  collocated  objects  is  a  local  issue. 

8  Refer  to  section  10  of  X.402  and  ISO/IEC  10  021-2  and  IS  7498-2. 

9  These  services  are  expected  to  be  provided  by  non-standard 
management  services  and  are  therefore  outside  the  scope  of  this 
Implementors  Agreement. 

10  Non-Repudiation  of  Delivery  can  only  be  provided  when  the 
proof-of-delivery  service  is  used. 

11  Allocation  and  management  of  sequence  numbers  is  outside  the 
of  this  Implementors  Agreement  (as  it  is  subject  to  bilateral 
agreements ) . 


10.5    Security  Class  OA  (SOa) 


10.5.1      Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  Implementation  in  order  to  provide  the  following: 

a)  Security  Functionality  defined  in  security  class  SO;  and, 

b)  Content  Confidentiality. 


10.5.2      Security  Services  for  SOa 

Security  class  OA  (SOa)  mandates  the  security  services  of  class  SO  plus  those  listed  in  table  16. 


Table  16  -  Security  class  OA  (SOa) 


Security  Interface 

1 
UA/ 
UA 

2 

UA/ 
MS 

3 

MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 

MS/ 
UA 

9 

MS/ 
UA 

Security  Service 

Data  Confidentiality 

Content  Confidentiality 

M 
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10.6.1      Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  implementation  in  order  to  provide  the  following: 

a)  Authentication  of  MTA,  MS,  and  UA; 
)i  ;i         b)  Confidentiality  of  connections  between  MTA,  MS,  and  UA; 

c)  Integrity  of  message  content; 

d)  Authentication  of  message  originator; 

i|  '         e)  Authentication  of  message  delivery  (Proof  of  delivery); 

|i  f)  MLS-features  of  MTA,  MS,  and  UA; 

i|  r        g)  MLS-separation  of  messages,  probes,  and  reports;  and, 

h)  MLS-mediation  by  secure  access  measures. 

NOTES 

1  The  level  of  assurance  of  the  MLS  trusted  components  is  subject  to  bilateral  agreement. 
1  2  The  level  of  accountability  provided  is  subject  to  bilateral  agreement. 

1|b.6.2      Security  Services  for  SI 

Security  class  1  (S1)  mandates  the  security  servicesof  class  SO  plus  those  listed  in  table  17. 
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Table  17  -  Security  class  1  (Si) 


1 

X 

UA/ 
UA 

9 
Z 

UA/ 
MS 

•J 
■J 

MS/ 
MTA 

A 
*± 

UA/ 
MTA 

MTA/ 
MS 

D 

MTA/ 
MTA 

7 

MTA/ 
UA 

Q 

MS/ 
UA 

MS/ 
UA 

Security  Service 

Origin  Authentication 

M^CQArr^   OriniTi    Aii'hhonl"  "i  r'^i' i  <^n 
X  ico  a  ciM  V    wi-  X  <^  J.  11          i^ii^iii*  xwc&c  x  wii 

m1 

I 

I 

Secure  Access  Management 

Peer  Entity  Authentication^'* 
Security  Context 

Ml 
Ml 

Ml 
Ml 

Ml 
Ml 

- 

M-"- 

Data  Integrity  Services 
Content  Integrity 

Ml 

Message  Security  Labelling*^ 

Ml 

Ml 

Ml 

m1 

Ml 

Ml 

Ml 

Ml 

Ml 

Security  Management  Services 
Change  Credentials 
Register 
MS-Register 

M 
M 
M 

M 
M 

M 

l5 

M 

Notes 

1  Shall  always  be  used. 

2  Only  provided  to  the  message  recipient. 

3  Using  either  symmetric  or  asymmetric  algorithms  as  identified  by 
the  algorithm  identifier  in  the  applicable  protocol  element. 

4  Authentication  between  collocated  objects  is  a  local  issue. 

5  These  services  are  expected  to  be  provided  by  non-standard 
management  services  and  are  therefore  outside  the  scope  of  this 
Implementors  Agreement. 

10.7    Security  Class  1A  (S1a) 

10.7.1  Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  implementation  in  order  to  provide  the  following: 

a)  Security  functionality  defined  for  security  class  Si ;  and, 

b)  Content  Confidentiality. 

10.7.2  Security  Services  for  SI  a 

Security  class  2A  (SI a)  mandates  the  security  services  of  class  SI  plus  those  listed  in  table  18. 
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Table  18  -  Security  class  1A  (Sla) 


Security  Interface 

1 
UA/ 
UA 

2 
UA/ 
MS 

3 

MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 

MS/ 
UA 

9 

MS/ 
UA 

Security  Service 

Data  Confidentiality 

Content  Confidentiality 

M 

10.8    Security  Class  2  (S2) 

10.8.1  Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  implementation  in  order  to  provide  the  following: 

a)  Security  functionality  defined  for  security  class  S1;  and, 

b)  Authentication  and  non-repudiation  of  messages,  probes,  and  reports. 

10.8.2  Security  Service  tor  S2 

Security  class  2  (S2)  mandates  the  security  services  of  class  S1  plus  those  listed  in  table  19. 
'  Table  19  -  Security  class  2  (S2) 


Security  Interface 

1 
UA/ 
UA 

2 

UA/ 
MS 

3 

MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 

MS/ 
UA 

9 

MS/ 
UA 

Security  Service 

Origin  Authentication 

Message  Origin  Authentication-^ 
Probe  Origin  Authentication 
Report  Origin  Authentication 
Proof  of  Submission 

Ml 

M^ 

Ml 

Ml 

Ml 

M 

Non-Repudiation 

Non-Repudiation  of  Origin 
Non-Repudiation  of  Submission 
Non-Repudiation  of  Delivery 

m5 
m5 

m2 

m2 

m2 

Notes 

1  Shall  always  be  used. 

2  Using  an  asymmetric  mechanism  (i.e.,  certificates  and  tokens  which 
are  not  repudiable  for  authentication  within  MTAs  and  the  MTS. 

3  Using  the  Message  Origin  Authentication  Check  as  detailed  in  the 
base  standard. 

4  Shall  always  be  used,  and  corrects  table  7  in  X.402. 

5  Using  either  a  trusted  notary  (symmetric)  or  using  certificates 
tokens  which  are  not  repudiable  (asymmetric). 
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10.9    Security  Class  2A  (S2a) 

10.9.1  Security  Functionality 

Security  measures  shall  be  provided  by  the  MHS  Implementation  in  order  to  provide  the  following: 

a)  Security  functionality  defined  for  security  class  S2;  and, 

b)  Content  Confidentiality. 

10.9.2  Security  Services  for  S2a 

Security  class  2A  (S2a)  mandates  the  services  of  class  S2  plus  those  listed  in  table  20. 


Table  20  -  Security  class  2A  (S2a) 


Security  Interface 

1 
UA/ 
UA 

2 

UA/ 
MS 

3 

MS/ 
MTA 

4 

UA/ 
MTA 

5 

MTA/ 
MS 

6 

MTA/ 
MTA 

7 

MTA/ 
UA 

8 

MS/ 
UA 

9 

MS/ 
UA 

Security  Service 

Data  Confidentiality 

Content  Confidentiality 

M 

1 1    Specialized  Access 

11.1  Physical  Delivery 

1 1 .2  Other  Access  Units 

11.2.1  Facsimile  Access  Units 

NOTE  -  The  possible  development  of  Agreements  in  this  area  is  for  further  study. 

1 1 .2.2  Telex  Access  Units 

It  is  not  currently  intended  to  develop  Agreements  in  this  area. 
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12  Redirection 

The  redirection  functional  group  is  for  further  study. 


13   IPM  Service 


13»1  Introduction 

This  clause  specifies  the  requirements  for  a  minimal  1988-based  IPMS  implementation  (i.e.,  IPM  UA)  which 
is  capable  of  intenworking  with  1 984-based  UAs. 

Such  a  minimal  1 988-based  UA  will  have  the  following  capabilities  in  order  to  achieve  inten/vorking  with  1 984- 
based  UAs  and  to  facilitate  migration  to  full  1988  operation: 

a)  It  will  continue  to  support  content  type  P2  (encoded  as  integer  2)  on  origination  and  reception; 

b)  It  will  support  receipt  of  P2  (encoded  as  integer  22); 

c)  It  may  originate  P2  encoded  as  integer  22,  but  the  guidelines  specified  in  section  8.18.2  of  X.420 
(1988)  are  to  be  followed,  i.e.,  the  content  type  shall  be  encoded  as  integer  2  unless  1988  P2 
protocol  elements  are  present.AII  1PM  UAs  must  support  either  MTS  Submission  and  Delivery  based 
on  the  protocol  classifications  in  clause  A.3,  or  MS  Submission  and  Retrieval  based  on  the  protocol 
classifications  in  clause  A.4.  However,  how  such  information  is  conveyed  to/from  the  MTS  or  MS 
in  the  case  of  a  collocated  UA  is  a  local  matter,  and  will  not  necessarily  be  subject  to  conformance 
verification. 


13.2    Elements  of  Service 

This  clause  specifies  the  requirements  for  support  of  1PM  Elements  of  Service  by  a  UA  conforming  to  the 
1PM  Kernel  Functional  Group  of  this  Agreement. 

The  classification  scheme  for  support  of  Elements  of  Service  is  as  defined  in  clause  5.2. 

The  requirements  for  support  of  1PM  Elements  of  Service  for  origination  and  reception  are  distinguished. 
Elements  of  Service  which  are  new  in  the  1988  MHS  standards  are  indicated  as  (1988). 

A  UA  must  support  those  Basic  1PM  Elements  of  Sen/ice  and  IPM  Optional  User  Facilities  defined  in  section 
19  of  X.400  (1988)  as  listed  and  qualified  in  tables  24  and  25. 
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Table  24  -  IPM  kernel:  basic  IPM  elements  of  service 


Element  of  Service 

Orig 

Recep 

»#1 

M-^ 

».l 

M-^ 

Content  Type  Indication 

M 

M 

Converted  Indication 

M 

Delivery  Time  Stamp  Indication 

- 

M 

IP-message  Identification 

M 

M 

Message  Identification 

M 

Non-delivery  Notification 

M 

Original  Encoded  Information 

Types  Indication 

M 

M 

Submission  Time  Stamp  Indication 

M 

M 

Typed  Body 

M 

^1 

User/UA  Capabilities  Registration 

(1988) 

M-L 

Notes 

1    In  the  case  of  a  collocated  UA/MTA  or 

collocated 

UA/MS,  the  method  and  extent  to 

which 

this 

Element  of 

Service  is  provided  is  a  local 

matter ; 

it  is  not 

necessarily  testable  in  the  absence  of 

support  for  the 

P3  or  P7  protocol. 
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Table  25  -  iPM  kernel:  IPM  service  optional  user  facilities 


KJL  1  g 

r\X  C  'ti  L  llcL.  V  "    rvtiO  ±  ^  i,  rill  L.    AX  X^w'WtrU 

O 

nU  ^iJ.^X  X  <^  X            Uo  C2  X  9     X.  liLl  X         U  X  \JIL 

n 

M 

Au.                  Wax             X 110 X  wax.  XUil 

n 

M 
1*1 

CXXIiu                           X  px  c;£JL       XIIU  X        L  XvJXX 

KJ 

M 

Fl 

IsOuy    ira.LT,    JLIiCxypi.  XOIl    XIiuxCaL  XOIl 
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VJ 

1*1 

i^oiiV6 X  s  X on  ir  x  oni Dx   X on 
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u 

vr 
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M 
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M 
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M 

TiT.   "pYri^m  cs  i  r\r\    Proh  "il^i'f'ja^^  ^lQRft\ 

M 

iLxp  xxy   x'aL'tf    xiiuxwdux  on 

n 

M 

Evrjl  i  o  i  "h   Oonvpr  s  i  on 
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0 
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M 
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M 

Ol*icol  f^'hino    Tn^^io^^^i  on 

X/  X  C  C  X  ^x^      X  XXLX  X  V^a  U  X  X/Xx 

0 

M 

Orininai"or   Tndicai"i on 

X  X  ^  X  XX a        X     X  XX x  w  n     x  ^yxx 

M 

M 

Originator  Requested  Alternate 

Recipient  (1988) 

0 

Prevention  of  Non-delivery  Notification 

0 

Primary  and  Copy  Recipients  Indication 

M 

M 

Probe 

0 

Receipt  Notification  Request  Indication 

0 

0 

Redirection  Disallowed  by  Originator  (1988) 

0 

Redirection  of  Incoming  Messages  (1988) 

0 

Reply  Request  Indication 

0 

M 

Replying  IP-message  Indication 

M 

M 

Requested  Delivery  Method  (1988) 

M 
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Table  25  -  IPM  kernel:  IPM  service  optional  user  facilities  (concluded) 


Element  of  Service 

Orig 

Recep 

Restricted  Delivery  (1988) 

0 

Return  of  Content 

0 

Sensitivity  Indication 

0 

M 

Subject  Indication 

M 

M 

Use  of  Distribution  List  (1988) 

0 

Notes 

1  Other  UA  Elements  of  Service  are  listed  in  Table  4. 

2  Support  of  Non-Receipt  Notification  Request  on 
reception  does  not  require  the  capability  to  generate 
a  non-receipt  notification  in  the  case  of  an 
implementation  in  which  a  non-receipt  condition  cannot 
occur . 

13.3    Interpersonal  Messaging  Protocol  (P2) 

The  requirements  for  support  of  Interpersonal  Messaging  Protocol  (P2)  elements  are  detailed  in  clause  A.2. 


13.4     Body  Part  Support 

This  clause  specifies  the  requirements  for  support  of  1PM  body  part  types  by  a  UA  conforming  to  this 
Agreement. 

The  requirements  for  support  of  IPM  body  part  types  for  origination  and  reception  are  distinguished.  Body 
part  types  which  are  new  in  the  1988  MHS  standards  are  indicated  as  (1988). 

A  UA  must  support  those  IPM  body  part  types  defined  in  Annex  E  of  X.420  (1988)  as  listed  and  qualified  in 
table  33  of  Annex  A  of  this  chapter.  If  an  implementation  supports  a  particular  body  part  type  for  reception, 
it  should  also  be  able  to  support  that  body  part  type  for  reception  if  it  is  part  of  a  forwarded  message.  If 
an  implementation  supports  origination  of  fonA/arded  messages,  it  must  be  capable  of  forwarding  every  body 
part  that  is  supported  on  reception.  The  reception  requirements  on  the  UA  do  not  necessarily  include  the 
ability  to  render  (display)  all  of  the  characters  received.  If  the  message  is  forwarded,  the  UA  must  transmit 
exactly  equivalent  characters,  but  not  necessarily  from  the  same  character  set. 

Any  basic  body  part  type  that  is  supported  on  reception  must  be  supported  as  integer  encoding  (ASN.1 
context-specific  identifier)  and  as  object  identifier  (externally-defined)  encoding. 

All  body  parts  with  integer-encoded  identifiers  in  the  range  0  up  to  and  including  16K-1  are  legal.  Body  part 
integer-encoded  identifiers  corresponding  to  X.I 21  country  codes  should  be  interpreted  as  described  in 
figure  10.  These  privately-defined  body  part  types  are  specified  as  an  interim  measure  to  provide  backward 
compatibility  with  1984  MHS  implementations.  For  intenA/orking  between  UAs  based  on  the  1988  (or  later) 
MHS  standards,  it  is  strongly  recommended  that  the  externally-defined  body  part  be  used  instead. 
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BodyPart 
ia5-text 


CHOICE  { 

[0]  lASTextBodyPart, 


oda-1984 
iso-6937 

bilaterally-defined 
externally-defined 


[12]   IMPLICIT  OCTET  STRING, 

[13]  IS06937BodyPart, 

[14]  Unidentified, 

[15]  ExternallyDef inedBodyPart , 


[310]  IMPLICIT 

USAPrivatelyDef inedBodyParts , 


Unidentified  :=  OCTET  STRING 

The  content  of  the  ODA  OCTET  STRING  will  contain  a  value  of 
type  ODABodyPart  as  follows: 

ODABodyPart  ::=  SEQUENCE  { 
ODABodyPartParcuneters , 
ODAData  } 

The  Parameters  and  Data  components  are  defined  in  Annex  E 
of  CCITT  Recommendation  T.411  (1988)   (ISO  8613-1). 

USAPrivatelyDef inedBodyParts  are  defined  as: 


These  privately-defined  body  part  types  are  specified  as  an 
interim  measure  to  provide  backward  compatibility  with  1984 
MHS  implementations.     For  interworking  between  UAs  based  on 
the  1988  (or  later)  MHS  standards,  it  is  strongly 
recommended  that  the  externally-defined  body  part  be  used 
instead. 

The  undefined  bit  in  PI  EncodedlnformationTypes  must  be  set 
when  a  message  contains  a  privately  defined  body  part.  Each 
UA  that  expects  such  body  parts  should  include  undefined  in 
the  set  of  deliverable  EncodedlnformationTypes  it  registers 
with  the  MTA. 

Body  part  numbers  are  interpreted  relative  to  the  body  part 
type  in  which  they  are  used.    OIW  registers  body  part 
numbers  for  privately-defined  formats  within  the  United 
States . 


SEQUENCE  {BodyPartNumber ,  ANY} 


BodyPartNumber 


INTEGER 


Figure  10  -  Privately-defined  body  parts 
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The  IPM  MS  provides  more  flexible  access  to  the  general  attributes  (see  clause  A.8,  table  43,  enhanced 
column)  as  well  as  supporting  IPM  attributes  (see  clause  A.10). 

IPM  UAs  can  make  use  of  either  the  Basic  MS  or  the  IPM  MS. 

Clause  A.10  is  to  be  read  in  accordance  with  annex  C  or  Recommendation  X.420  (1988). 

An  IPM  MS  requires  support  from  both  the  General  Attributes  and  IPM  Attributes  as  specified  in  clauses  A.8 
and  A.10,  respectively. 


13.5.1      Implementation  of  the  IPM  MS  with  1984  Systems 

While  the  Message  Store  is  part  of  the  1988  MHS  standards,  implementation  of  MS  services  with  a  1984  MTA 
is  possible.  In  order  to  interoperate  with  other  1984  MHS  systems,  implementations  with  this  configuration 
should  adhere  to  the  following  guidelines: 

a)  The  UA  must  generate  1984  P2  PDUs; 

b)  The  UA  must  identify  the  content  protocol  as  integer  2  to  the  MS; 

c)  The  MS  must  be  collocated  with  the  MTA  unless  1988  P3  support  is  provided  on  the  1984  MTA 
as  well. 

To  meet  these  guidelines,  the  UA  may  be  implemented  as  follows: 

a)  The  UA  could  conform  to  X.420  (1984),  with  1988  UA  extensions  for  utilizing  the  MS  services; 

b)  The  UA  could  be  a  1988  UA  with  restrictions  on  protocol  elements  generated  and  by  identifying 
the  content  type  as  integer  2  rather  than  22.  No  1988-specific  elements  should  be  generated. 

Details  of  the  interface  between  the  1988  MS  and  the  1984  MTA  when  collocated  are  beyond  the  scope  of 
these  Agreements. 


13.6     Body  Part  Conversion  Functional  Group 


13.6.1  General 

The  Body  Part  Conversion  Functional  Group  supports  the  functionality  required  to  perform  the  action  of 
message  body  part  conversion.  The  Element  of  Service  "Conversion  Prohibition"  is  made  mandatory  in  the 
MT  Kernel. 
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13.6.2      Elements  of  Service 

The  Body  Part  Conversion  Functional  Group  provides  support  for  the  following  Elements  of  Service. 

Table  25  -  Conversion:  MT  elements  of  service 


Element  of  Service 

Support 

Conversion  Prohibition  in  Case 
of  Loss  of  Information  (1988) 
Explicit  Conversion 
Implicit  Conversion 

Notes 

1    At  least  one  of  explicit  or  implicit  conversion  must 
be  supported  for  conformance  to  this  functional  group. 

Operational  Notes 

Conversions  to  and  from  General  Text  can  only  be  performed  through  implicit  conversion.  Among  possible 
implicit  conversions  are  the  following: 

a)  Teletex  to  General  Text; 

b)  IA5  Text  to  General  Text; 
^,         c)  General  Text  to  Teletex; 

d)  General  Text  to  IA5  Text. 

13.6.3  Conformance 

An  implementation  conforming  to  this  functional  group  shall  conform  to  the  procedures  for  the  Elements  of 
Service  in  clause  13.6.2,  and  shall  obey  the  rules  defined  in  clauses  14.3.5  and  14.3.9  of  X.411  /  ISO/IEC 
10021-4. 


The  PICS  shall  document  which  body  part  conversions  the  implementation  can  perform,  both  for  implicit 
and  explicit  conversion,  and  whether  "Conversion  Prohibition  in  Case  of  Loss  of  Information"  is  supported. 
Conformance  to  this  functional  group  does  not  mandate  conversion  between  any  two  specific  body  part 
types. 

If  conversion  has  to  take  place  and  the  Element  of  Service  "Conversion  Prohibition  in  Case  of  Loss  of 
Information"  is  requested,  then  the  MTA  is  not  allowed  to  perform  the  conversion  if  loss  of  information  may 
occur,  according  to  the  classification  in  clause  2.1  of  X.408. 

If  the  General  Text  body  part  type  is  supported,  the  implementation  must  support  two-way  conversion 
between  the  General  Text  IA5  subrepertoire  and  the  IA5  Text  body  part. 

If  a  UA  is  registered  to  receive  multiple  Encoded  Information  Types  and  its  MTA  receives  a  message  for  it 
containing  any  of  those  registered  EITs,  the  corresponding  body  parts  shall  not  be  converted  prior  to 
delivery. 
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13.7  Security 

There  are  no  security  requirements  to  support  IPM,  above  and  beyond  those  specified  in  clause  10. 


13.8    Error  Handling 

NOTE  -  For  further  study. 


13.9     Physical  Delivery 


14   EDI  Messaging  Service 


15   Use  of  Underlying  Layers 


15.1     MTS  Transfer  Protocol  (PI) 

The  P1  protocol  is  mapped  onto  the  Reliable  Transfer  Service  Element  (RTSE)  either  in  X.410-1984  mode 
or  in  normal  mode,  as  specified  in  clause  5.3.  In  X.410-1984  mode,  the  RTSE  makes  direct  use  of  the 
services  provided  by  the  Session  Layer,  as  specified  in  part  5  (Upper  Layers)  of  the  Stable  Implementation 
Agreements.  In  normal  mode,  the  RTSE  makes  use  of  the  services  provided  by  the  Association  Control 
Service  Element  (ACSE)  and  Presentation  Layer,  as  defined  in  part  5  (Upper  Layers)  of  these  Agreements. 


15.2    MTS  Access  Protocol  (P3)  and  MS  Access  Protocol  (P7) 

The  P3  and  P7  protocols  make  use  of  the  services  provided  by  the  Remote  Operations  Service  Element 
(ROSE),  Association  Control  Service  Element  (ACSE),  Presentation  Layer,  and,  optionally,  the  Reliable 
Transfer  Service  Element  (RTSE),  as  defined  in  part  5  (Upper  Layers)  of  these  Agreements.  It  is 
recommended  that  RTSE  be  used  for  recovery  purposes  when  the  implementation  does  not  use  Transport 
Class  4  or  there  is  a  high  prot>ability  of  an  association  failure. 
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16   Error  Handling 

This  clause  describes  appropriate  actions  to  be  taken  upon  receipt  of  protocol  elements  which  are  not 
supported  in  these  Implementation  Agreements:  malformed  PDUs,  unrecognized  0/R  Name  forms,  content 
errors,  errors  in  reports,  and  unexpected  values  for  protocol  elements. 

An  implementation  must  be  able  to  report  all  error  conditions  which  may  occur  with  the  appropriate  error 
information  as  defined  in  the  referenced  base  standards.  An  implementation  must  be  able  to  handle  receipt 
of  all  error  indications  which  are  defined  in  the  referenced  base  standards.  An  implementation  must  also  be 
tolerant  of  any  additional  error  indications  which  are  not  currently  defined,  but  is  not  required  to  be  able  to 
interpret  such  error  information. 


16.1     PDU  Encoding 

NOTE  -  For  further  study. 


16.2  Envelope 

NOTE  -  For  further  study. 


16.3  Reports 

NOTE  -  For  further  study. 


16.4    Pragmatic  Constraints 

if  an  implementation  detects  a  pragmatic  constraint  violation,  then  it  may  generate  an  appropriate  error 
indication  but  is  not  required  to  do  so. 


17  Conformance 

For  this  clause,  the  term  conformance  is  as  defined  in  ISO  9646. 

Bilateral  agreements  between  domains  may  be  implemented  in  addition  to  the  requirements  stated  in  this 
document.  Conformance  to  this  Agreement  requires  the  ability  to  exchange  messages  without  use  of 
bilateral  agreements. 

In  order  to  achieve  a  more  precise  definition  of  conformance  requirements  according  to  the  functionality 
supported  by  an  implementation,  the  concept  of  Functional  Groups  has  been  introduced.  A  Functional 
Group  is  a  set  of  related  Elements  of  Service  and  associated  protocol  elements  which  provide  a  discrete 
area  of  functionality. 
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Conformance  to  this  Agreement  requires  as  a  minimum  tliat  all  Mandatory  Elements  of  Service  listed  in  this 
part  are  supported  in  the  manner  defined  in  the  MHS  standards,  as  qualified  in  this  Agreement,  for  each  of 
the  Functional  Groups  claimed.  Any  Optional  Elements  of  Service  for  which  support  is  claimed  must  also 
be  supported  as  defined  in  the  MHS  standards  and  as  qualified  in  this  Agreement.  Pragmatic  constraints 
shall  be  observed  as  specified  in  the  CCITT  X.400  (1988)  Series  of  Recommendations.  It  is  not  necessary 
to  implement  the  recommended  practices  of  annex  D  in  order  to  claim  conformance  to  this  Agreement. 

Conformance  requirements  for  support  of  Functional  Groups  by  particular  configuration  types  (see  clause 
1)  are  listed  in  table  30.  An  implementation  may  claim  conformance  to  multiple  configuration  types  (e.g. 
"MTA+UA"  and  "Class  B  MTA  only"). 


Table  30  -  Conformance  requirements 


Functional  Group 


Configuration^ 


MTA 
+  2 


MTA 

+ 
MS 


MTA  Only-' 


B 


MS 
+ 

UA 


MS 
Only 


UA  Only 


P7  P3 


MT  Kernel 
Message  Store* 
Remote  UA 
Distribution  List 
Directory 
MHS  Management 
Security 
Redirection 
Physical  Delivery 
Other  Access  Units 
IPM  Service^ 
EDI  Service" 


M^ 


0 

0 
* 

0 
* 

* 


M 
M 

0 

0 
* 

0 
* 

* 

* 

0 
0 


M 


M 

M 

0 

0 
* 

0 
* 
* 
* 

0 
0 


M 


0 

0 
* 

0 
* 
* 
* 

0 
0 


M 

* 

0 
* 

0 
* 
* 
* 


M 


0 
* 

0 
* 
* 
* 

0 
0 


M 

* 

0 
* 

0 
* 

* 


M 
* 

0 
* 

0 
* 

* 

* 

0: 


Notes 

1  There  are  three  conformance  classes  defined  for  the 
MT  Kernel  in  clause  17.1. 

2  Optional  elements  of  a  context-specific  UA  need  not  be 
supported  in  the  MT  Kernel  in  this  configuration,  for 
example  Probe  and  Deferred  Delivery  Cancellation. 

3  The  designation  of  a  '+'   in  a  configuration  (e.g., 
'MTA+MS')  implies  that  there  is  no  exposed  protocol  in 
the  interface  between  the  two  components. 

4  There  are  two  conformance  levels  defined  in  clause 
17.2  for  MS  support. 

5  At  least  one  of  the  content-specific  functional  groups 
must  be  supported. 

6  The  content-specific  functional  groups  may  include 
requirements  for  levels  of  support  by  an  MS  and/or  MTA 
(e.g.,  in  terms  of  attributes  supported,  conversion 
requirements,  etc.).  In  table  29,  the  support  of  a 
content-specific  functional  group  by  the  MS  only  implies 
support  of  the  MS  requirements  for  that  content  type 
(i.e.,  attribute).  Similarly,  support  in  the  MTA  for  a 
content-specific  functional  group  only  implies  support 
for  the  MTA  requirements  for  that  content  type  (e.g., 
conversion) . 
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17.1     MT  Kernel  Conformance  Classes 

The  MT  Kernel  conformance  classes  are: 

a)  A  class  "A"  MT  Kernel  implementation  conveys  a  message,  probe,  or  report  to  another  MT  Kernel 
'       using  standard  means.  A  class  "A"  MT  Kernel  is  specifically  implemented  in  order  to  transfer 

messages,  probes,  and  reports  which  have  previously  been  transferred  and  need  not  support 
submission  and  delivery.  A  class  "A"  MT  Kernel  may  perform  other  activities  such  as  originate 
reports,  expand  distribution  lists,  and  perform  conversions. 

b)  A  class  "B"  MT  Kernel  implementation  supports  submission,  delivery,  and  transfer  using  standard 
means,  i.e.,  P3  and  P1 .  A  class  'B'  MT  Kernel  need  not  support  the  transfer  of  previously  transferred 
messages,  probes,  or  reports. 

c)  A  class  "C"  MT  Kernel  implementation  requires  support  for  transfer  of  messages,  probes,  and 
reports  to  another  MT  Kernel  using  standard  means.  A  class  "C"  MT  Kernel  does  not  require  support 
for  the  transfer  of  previously  transferred  messages,  probes,  and  reports,  and  message  submission 
and  delivery  is  achieved  by  non-standard  means. 

An  MTA  may  conform  to  one  or  more  of  the  MT  Kernel  classes.  For  example,  a  class  "B"  or  "C"  MT  Kernel 
which  supports  the  transfer  of  previously  transferred  messages,  probes,  and  reports  is  also  conformant  to 
a  class  'A'  MT  Kernel.  Figure  11  illustrates  several  combinations  of  MT  Kernel  conformance  classes. 
Additional  combinations  are  possible. 


UA 


MS 


Standard 
Non-standard 


Figure  11  -  MT  kernel  conformance  classes 


17.2    MS  Conformance  Levels 

The  MS  conformance  levels  are: 

a)  A  Basic  MS  only  requires  support  for  the  General  Attributes  as  specified  in  clause  A.8,  basic 
column  of  table  43; 

b)  An  enhanced  MS  requires  support  for  more  of  the  General  Attributes  as  specified  in  clause  A.8 
(enhanced  column); 

c)  A  Secure  MS  additionally  requires  support  for  the  attributes  as  specified  in  clause  A.9. 
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For  content-specific  MS  requirements,  see  the  appropriate  content-specific  clauses. 


18   Management  Donnain  Agreements 

The  sections  above  describe  agreements  among  implementors  of  particular  X.400  components  (e.g.,  MTAs, 
UAs,  MSs).  There  are  some  agreements  that  don't  apply  to  a  single  X.400  component,  but  instead  apply  to 
an  entire  domain  of  X.400  components.  This  section  details  any  requirements  for  X.400  domains. 
Independent  of  those  for  individual  X.400  components.  A  single  X.400  component  cannot  be  conformance 
tested  for  these  domain  requirements,  but  for  a  domain  to  claim  to  be  "operationally  OIW  compliant,"  it  must 
abide  by  the  rules  stated  below. 


18.1     Management  Domain  Names 

This  section  contains  requirements  on  matters  being  considered  by  the  U.  S.  CCITT  Study  Group  D  for 
national  decisions.  Such  decisions  are  likely  to  supersede  the  relevant  portions  of  this  clause. 

The  Implementation  Agreements  for  1 984-based  MHS  implementations  requires  that  all  Management  Domain 
Names  (both  Private  and  Administration)  shall  be  unique  within  the  U.  S.  This  is  also  a  requirement  for  1988- 
based  MHS  implementations. 

A  "Construction  Syntax"  is  defined,  which  uses  a  registered  OSI  Organization  Name  from  the  ANSI  US 
Register  of  Organization  Names  as  a  "root"  in  the  construction  of  MHS  Management  Domain  Names  e.g., 
ADMD  and  PRMD).  The  constructed  combinations  based  on  this  "root"  will  be  guaranteed  to  be  unique,  and 
thus  be  safely  used  as  MHS  MD  names  in  the  United  States.  Other  countries  may  wish  to  adopt  these  same 
rules. 

MHS  MD  (PRMD  and  ADMD)  names  shall  be  constructed  according  to  the  Extended  BNF  grammar  shown 
in  figure  12. 


<ADMDName>  : : =  <MDName> 

<PRMDName>  : :  =  <MDNaine> 

<MDName>  : : = 

<NationalOrganizationName>  j 

<ConstructedName>  [ 

<Nat ionalOrganizationNumber> 

<ConstructedNaine>  ::  = 

<NationalOrganizationName> "+"<OrganizationallyDetenninedPart> 

Figure  12  -  Management  domain  name  construction 

Subject  to  all  of  the  following  rules: 

Rule  1.  The  entire  <MDName>  must  not  exceed  16  bytes  (including  any  constructor  operators  that 
may  be  included,  and  shall  be  composed  entirely  of  PrintableString  characters. 
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Rule  2.  The  <NationalOrganizationName>  shall  be  drawn  from  the  alphanumeric  names  registered 
in  the  US  Register.  It  shall  contain  at  least  one  non-numeric  character,  and  not  contain  the 
constructor  operator "  +  "  (plus  sign). 

Rule  3.  Each  <NationalOrganizationName>  obtained  from  the  US  Registry  will  be  accompanied  by 
a  NumberForm  (numeric  value)  which  shall  be  bound  as  the  <  NationalOrganizationNumber>  to  the 

<  NationalOrganizationName  > . 

Rule  4.  In  a  <  Constructed  Name  >,  the  <OrganizationallyDeterminedPart>  shall  be  certified  to  be 
unique    under    the    <  NationalOrganizationName >    (sub)authority,    by  the 

<  NationalOrganizationName  >  registration  authority. 

Rule  5.  A  <  NationalOrganizationN umber >  shall  be  obtained  from  the  US  Register  and  bound  to  the 

<  ConstructedName  > . 

Rule  6.  A  Private  Management  Domain's  PrivateDomainldentifier  shall  be  the  same  as  its 
PrivateDomainName. 

NOTES 

1  The  PRMD  names  resulting  from  the  <  ConstructedName >  syntax  (those  having  a  "  +  "  in  them)  are  atomic 
values  from  the  point  of  view  of  the  MTA  --  in  particular,  it  is  not  permissible  for  the  MTA  to  route  on 
components  of  the  PRMD  name. 

2  The  construction  rules  are  such  that  if  ABC  is  a  Registered  National  Organization  Name,  then  the  ow/ner  of 
,    that  name  controls  the  MHS  Domain  Name  space  including  "ABC"  and  "ABC +< anything >,"  but  not 

"ABC  <  anything  >." 

3  A  "  +  "  is  legal  in  an  ANSI  provided  name. 

'  4  If  a  Registered  Organization  Name  already  contains  the  construction  operator  ("  +  "  sign),  then  in  order  to 
use  the  name  as  an  <MDName>,  its  owner  must  also  register  the  "root"  which  precedes  the  first "  +  "  sign,  with 
the  US  Register  of  Organization  Names,  (e.g.,  company  B+Z  +  P  would  need  to  register  "B"  to  be  able  to  use 

'    the  "constructed"  name  of  B+Z  +  P.) 

i 

1     5   For  the  special  case  of  the  construction  operator  ("  +  "  sign)  being  the  first  character  of  a  Nationally 
I     Registered  Name,  no  special  action  is  required  beyond  its  normal  registration  with  the  US  Registry  of 
Organization  Names. 

^  6  If  the  sub-authority  determined  by  <  NationalOrganizationName  >  so  wishes,  the 
<OrganizationallyDeterminedPart>  can  be  constructed  using  rules  similar  to  the  above,  resulting  in  a 
hierarchical  construction  separated  by  "  +  "s.  In  particular,  the  sub-authority  must  maintain  its  own  registry  and 
might  (for  example)  define  the  <OrganizationallyDeterminedPart>  using  the  syntax 


<OrganizationallyDeterminedPart>     ::=    <Di visionName> 

]     <DivisionNaine>  "  +  "  <DivisionallyDeterininedPart> 

Figure  13  -  Name  construction  by  subauthorities 

where  the  <DivisionName>  is  drawn  from  the  sub-authority's  registry  (and  does  not  contain  a  "  +  ").  Thus 
the  sub-authority  can  delegate  the  use  of  the  prefix 
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<NationalOrganizati  onNeime> + <D  i  v  i  s  i  onName> 

Figure  14  -  Prefix 

to  someone  else. 


18.2     Use  of  ADMD  Names 

This  subsection  was  developed  by  an  X.400  SIG  working  group  in  April,  1990.  It  contains  extrennely 
controversial  positions  tiiat  invol<e  national,  commercial,  and  quality  of  service  issues.  The  OIW  may  not  be 
the  correct  forum  to  make  these  national  decisions.  Until  these  decisions  can  be  reached  or  a  national  forum 
established,  this  section  remains  as  a  placeholder  in  the  OIW  X.400  SIG  Working  Text  document  only. 

NOTE  -  Version  2  of  the  CCITT  X.400  Implementors  Guide,  dated  16  March  1990,  allows  for  a  single  zero  ("0") 
character  as  the  ADMD  name  for  the  case  of  a  PRMD  that  is  not  reachable  from  any  ADMD.  The  following 
discussion  does  not  apply  to  such  PRMDs. 

A  PRMD  may  be  directly  connected  to  more  than  one  ADMD.  Since  a  PRMD  may  not  alter  the  originators 
ORAddress,  the  Country /ADMD  name  pair  provided  in  the  Originator  ORAddress  may  not  match  those  of 
the  first  ADMD  to  receive  the  message  from  the  PRMD.  The  first  ADMD  is  required  to  accept  such  messages 
and  may  not  alter  the  originator's  ORAddress. 

Any  message  originated  by  a  PRMD  must  have  an  Originator's  ORAddress  that  either  uses  the  single  space 
ADMD  name  or  uses  a  Country /ADMD  name  pair  for  an  ADMD  to  which  the  PRMD  is  connected.  (In  both 
cases  the  Country  name  is  required.) 

The  X.400  Recommendations  have  defined  a  mechanism  that  enables  PRMDs  connected  to  multiple  ADMDs 
to  enter  a  single  space  as  the  ADMD  name.  To  support  this,  these  agreements  recognize  two  classes  of 
ADMDs.  ADMDs  in  the  first  class,  "space-supporting"  ADMDs,  must  be  able  to  route  on  PRMD  name, 
independently  from  the  ADMD  name.  Furthermore,  the  space-supporting  ADMDs  must  arrange  their  routing 
configuration  such  that  all  PRMDs  are  reachable  from  all  ADMDs.  PRMDs  using  the  single  space  ADMD 
name  must  be  connected  to  at  least  one  space-supporting  ADMD. 

ADMDs  in  the  other  class,  "non-space-supporting"  ADMDs,  must,  at  a  minimum,  route  messages  for  which 
the  ADMD  name  is  a  single  space  to  a  space-supporting  ADMD  (In  the  indicated  country).  It  is  hoped  that 
in  the  long  term,  all  ADMDs  will  be  able  to  route  on  the  PRMD  name  when  the  ADMD  name  is  a  single 
space. 
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Annex  A  (normative) 

MHS  Protocol  Specifications 

Tables  31  through  48  specify  the  requirements  for  support  of  MHS  protocol  elements  for  conformance  to 
this  Agreement.  It  should  be  noted  that  the  tables  specify  minimum  support  for  conformance  to  the  relevant 
Kernel  functional  groups  and  where  appropriate  also  specify  enhanced  support  requirements  where  one  or 
more  further  functional  groups  are  claimed.  All  element  support  is  subject  to  further  review  and  may  be 
upgraded  in  later  versions  of  this  Agreement. 

Within  the  classification  tables  (32-48),  the  column  "S"  indicates  the  classification  from  the  base  standards. 
This  is  provided  for  reference  purposes  only  and  is  intended  to  be  in  agreement  with  the  base  standards. 

The  protocol  support  classification  scheme  used  in  this  version  of  this  Agreement  is  described  below. 
However,  it  should  be  noted  that  the  scheme  is  currently  under  review  both  within  the  OIW  X.400  SIG 
and  in  the  EWOS/ETSI  MHS  groups  and  is  likely  to  be  revised  for  later  versions  of  this  Agreement. 

The  classification  of  support  for  a  protocol  element  specifies  the  requirements  for  implementations 
conforming  to  this  Agreement  to  be  able  to  generate,  receive  and  process  that  protocol  element,  as 
appropriate  (the  'receiving'  role  includes  relaying  where  appropriate).  The  classification  of  support  for  each 
protocol  element  is  relative  to  that  for  its  containing  element.  Where  sub-elements  within  a  containing 
element  are  not  listed,  then  their  support  classification  shall  be  assumed  to  be  that  of  the  containing 
element.  Where  the  range  of  values  to  be  supported  for  an  element  is  not  specified,  then  all  values  defined 
in  the  base  standard  shall  be  supported. 

The  classifications  have  been  revised.  The  former  classifications  relate  to  the  classifications  in  Part  7  of  the 
Stable  Agreements  as  shown  in  table  31. 


Table  31  -  Classification  changes 


Former 
Category 

New 

Originator 
Category 

Recipient 
Category 

Generatable  (G) 
Supported  (H) 
Mandatory  (M) 
Required  (R) 
Unsupported  (X) 

Mandatory  (M) 
Optional  (0) 
Mandatory  (M) 
Mandatory  (M) 
Optional  (0) 

Mandatory  (M) 
Mandatory  (M) 
Mandatory  (M) 
Mandatory  (M) 
Optional  (0) 

The  support  classifications  are  stated  for  both  Origination  and  Reception  (0/R)  in  the  following  tables  (32- 
48).  The  defined  support  for  each  is  stated  within  each  classification. 

Implementations  conforming  to  this  Agreement  must  be  capable  of  accepting  the  syntax  of  every  protocol 
element  of  a  protocol  for  which  support  is  claimed.  When  an  MS  or  MTA  receives  a  protocol  element  that 
according  to  the  base  standard  should  be  conveyed  to  another  MHS  entity  (MTA,  MS,  or  UA),  the  MS  or 
MTA  is  required  to  preserve  the  semantics  of  that  protocol  element  in  the  PDU  conveyed.  Notwithstanding 
the  above,  criticality  must  be  observed  according  to  the  base  standard. 
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Mandatory  (M)  on  Origination:  Implementations  conforming  to  this  Agreement  shall  generate  this 
element  in  all  information  objects  in  which,  according  to  the  base  standards,  it  shall  occur. 

Mandatory  (M)  on  Reception:  Implementations  conforming  to  this  Agreement  shall  process  this 
element  appropriately  according  to  its  semantics. 

Optional  (0)  on  Origination:  Where  this  element  is  not  conveyed  from  one  MHS  entity  to  another, 
implementations  conforming  to  this  Agreement  may  optionally  be  capable  of  generating  this 
protocol  element,  but  are  not  required  to  do  so. 

Optional  (0)  on  Reception:  Implementations  conforming  to  this  Agreement  may,  but  are  not 
required  to  be  capable  of  processing  this  protocol  element. 

NOTE  -  Some  protocol  elements  may  not  be  conveyed,  if  downgrading  rules  are  applied. 

To  Be  Determined  (*):  the  support  classification  for  this  protocol  element  has  yet  to  be  determined. 

Not  Applicable  (-):  The  protocol  element  is  not  applicable  in  the  particular  context  according  to  the 
base  standard. 

Where  the  dynamic  behavior  of  protocol  elements  need  to  be  specified,  the  following  classification  scheme 
is  used: 

Mandatory  (m):  The  protocol  element  shall  always  be  implemented  and  generated.  On  reception, 
correct  action  shall  be  taken  as  specified  in  the  base  standard,  or  as  qualified  or  specified  in  these 
Agreements.  Absence  of  the  corresponding  protocol  element  shall  cause  the  appropriate  abstract 
error  to  be  generated. 

Excluded  (x):  The  protocol  element  shall  not  be  present  or  it  must  be  possible  to  prevent  its  use. 
Its  presence  shall  cause  the  appropriate  abstract  error  to  be  generated. 

Dynamic  conformance  classifications  are  indicated  in  a  single  column  of  each  of  the  Protocol  Element 
tables.  The  classification  applies  to  the  usage  only  of  the  protocol  elements  which  have  a  static  classification. 

There  are  two  types  of  tables  defining  support  for  protocol  elements:  the  first  is  a  base  table  that  contains 
and  classifies  all  protocol  elements,  and  the  second  is  a  delta  table  for  a  functional  group. 

Functional  group  tables  need  only  list  those  protocol  elements  for  which  the  functional  group  has  changed 
the  support  requirements  from  the  base  table.  Additional  containing  constructor  elements  may  be  listed  in 
order  to  provide  context  information. 

If  the  functional  group  changes  the  support  requirements  for  a  given  element  it  must  be  classified  in  the 
delta  table.  Changes  should  only  place  more  restrictions  on  the  required  support,  for  example  changing 
an  optional  element  to  be  either  mandatory,  excluded,  or  out  of  scope.  If  an  element  in  the  delta  table  is 
not  classified,  it  is  only  listed  for  context  information  and  the  required  support  for  it  is  the  same  as  its 
classification  in  the  base  table. 

The  Dynamic  column  is  only  filled  in  if  the  profile  changes  the  requirements  for  use  of  the  element  in  every 
PDU,  for  example,  if  support  for  the  element  is  required,  but  use  of  the  element  is  optional  in  a  given  PDU. 
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However,  if  you  are  supporting  a  functional  group  that  element  will  always  (or  never)  be  used. 


A.1      MTS  Transfer  Protocol  (P1) 

Within  Table  32,  the  columns  under  "Support  by  MT  Kernel  Class"  refer  to  the  MT  Kernel  Conformance 
Classes  defined  in  clause  17.1. 
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Table  32  -  Classification  of  the  Pi  protocol  elements 


MTS  Transfer  Protocol  (PI) 

Part     1  of  9 

Support  by  MT  Kernel 

Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

Operations 

MTABind 

M 

M/M 

M/M 

MTABind 

MTAUnbind 

M 

M/M 

M/M 

MTSE 

MessageTransf er 

M 

M/M 

M/M 

ProbeTransf er 

M 

M/M 

M/M 

ReportTransf er 

M 

M/M 

M/M 

See  Note  7 

Arguments/Results 

MTABind 

ARGUMENT 

<NULL> 

0 

0/M 

0/M 

See  Note  2 

<SET> 

0 

M/M 

M/M 

initiator-name 

M 

M/M 

M/M 

initiator-credentials 

M 

M/M 

M/M 

simple 

0 

M/M 

M/M 

strong 

0 

0/0 

0/0 

secur  i  ty-context 

0 

0/0 

0/0 

RESULT 

<NULL> 

0 

0/M 

0/M 

See  Note  2 

<SET> 

0 

M/M 

M/M 

responder-name 

M 

M/M 

M/M 

responder-credent  ials 

M 

M/M 

M/M 

simple 

0 

M/M 

M/M 

strong 

0 

0/0 

0/0 

MTS-APDU 

message 

M 

M/M 

0/M 

envelope 

M 

M/M 

M/M 

MessageTransf erEnvelope 

content 

M 

M/M 

M/M 

probe 

M 

M/M 

0/M 

ProbeTransf erEnvelope 

report 

M 

M/M 

M/M 

envelope 

M 

M/M 

M/M 

ReportTransf erEnvelope 

content 

M 

M/M 

M/M 

ReportTransf erContent 

MessageTransf erEnvelope 

message-identifier 

M 

M/M 

M/M 

MTSIdentif ier 

originator-name 

M 

M/M 

M/M 

ORName 

or iginal-encoded-informat ion- 

types 

0 

M/M 

0/0 

EncodedlnformationTypes 

content-type 

M 

M/M 

M/M 

built-in 

0 

M/M 

0/0 

external 

0 

0/M 

0/0 
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Table  32  -  Classification  of  the  P1  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part     2  of  9 

Support  by  MT  Kernel 

Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

content-ident i  f ier 

0 

0/M 

0/0 

priority 

0 

M/M 

0/M 

All  values 

per-message-indicators 

0 

M/M 

0/M 

disclosure-of -recipients 

0 

0/M 

0/M 

implicit-conversion-prohibited 

0 

M/M 

0/M 

alternate-recipient-allowed 

0 

M/M 

0/0 

content-return-request 

0 

0/0 

0/0 

defer red-deli very- time 

0 

0/0 

0/0 

per-domain-bi lateral- 

information 

0 

0/0 

0/0 

PerDomainBi lateral Info 

trace- information 

M 

M/M 

M/M 

Tracelnformation 

extensions 

0 

M/M 

M/M 

ExtensionField 

recipient-reassignment- 

prohibited  ' 

0 

M/M 

M/M 

dl-expans ion-prohibited 

0 

M/M 

0/M 

conversion-wi th-loss- 

prohibited 

0 

0/M 

0/M 

latest-deli very- time 

0 

0/0 

0/0 

See  X.411,  14.1.1  note  2 

originator-return-address 

0 

0/0 

0/0 

originator-certificate 

0 

0/0 

0/0 

content-confidentiality- 

algorithm—  identifier 

0 

M/M 

M/M 

See  Note  6 

message-origin- 

authentication-check 

0 

0/0 

0/0 

message-security-label 

0 

0/0 

0/0 

See  Note  5 

secur  i  ty-policy-ident  i  f ier 

0 

M/M 

M/M 

secur  i  ty-class  i  f icat  ion 

0 

M/M 

M/M 

privacy-mark 

0 

0/0 

0/0 

security-categories 

0 

M/M 

M/M 

content-correlator 

0 

0/0 

0/0 

JIT         _              _                •                    »      •    1     

dl-expans lon-history 

0 

0/M 

0/M 

DLExpans  ionHi  s  tory 

internal-trace- information 

0 

M/M 

M/M 

InternalTracelnfo 

per-recipient-f ields 

M 

M/M 

M/M 

recipient-name 

M 

M/M 

M/M 

ORName 

originally-specif ied- 

r  ec  i  p  i  en t -numbe  r 

M 

M/M 

M/M 

per-recipient- indicators 

M 

M/M 

M/M 

expl i  c  i  t -conve  r  s  i  on 

0 

0/0 

0/0 

extensions 

0 

0/M 

0/M 

ExtensionField 

or iginator-requested- 

alternate-recipient 

0 

0/0 

0/0 

requested-deli very-method 

0 

M/M 

0/M 

physical-forwar ding- 

prohibited 

0 

0/0 

0/0 

physical-f orwarding-address- 

request 

0 

0/0 

0/0 

phys  i  cal-del i very-modes 

0 

0/0 

0/0 
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Table  32  -  Classification  of  the  PI  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part     3  of  9 

Support  by  MT  Kernel 

Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

registered-mai 1-type 

0 

0/0 

0/0 

recipient-number-f or-advice 

0 

0/0 

0/0 

physical-rendition-attributes 

0 

0/0 

0/0 

physical-delivery-report- 

request 

o 

0/0 

/-\  //-\ 

o/o 

message- token 

0 

0/0 

0/0 

asymmetric-token 

0 

M/M 

M/M 

See  Note  5 

signature-algor i thm- 

ident  i  f ier 

M 

M/M 

M/M 

name 

M 

M/M 

M/M 

t  ime 

M 

M/M 

M/M 

s  ign— data 

O 

M/M 

M/M 

content— conf  i  dent  i  al i  ty— 

algorithm-identifier 

0 

M/M 

M/M 

content— integri  ty— check 

0 

M/M 

M/M 

message-security-label 

0 

0/0 

0/0 

proof -of -deli very-request 

0 

M/M 

M/M 

message-sequence-number 

0 

0/0 

0/0 

encrypt  ion— algorithm- 

identifier 

0 

M/M 

M/M 

encrypted-data 

0 

M/M 

M/M 

content -conf  i  dent  i  al i  ty-key 

0 

M/M 

M/M 

content-integr i  ty-check 

0 

M/M 

M/M 

message-security-label 

0 

0/0 

0/0 

content-integr i  ty-key 

0 

0/0 

0/0 

message-sequence-number 

0 

0/0 

0/0 

content— integri  ty-check 

u 

M/M 

M/M 

See  Note  6 

proof -of -deli very-request 

0 

M/M 

M/M 

See  Note  6 

redi  rect  ion— hi  story 

o 

O/M 

O/M 

ProbeTransfer Envelope 

probe— identi  f ier 

M 

M/M 

M/M 

MTSIdentif ier 

originator-name 

M 

M/M 

M/M 

ORName 

or iginal-encoded-informat ion- 

types 

0 

M/M 

0/0 

EncodedlnformationTypes 

content-type 

M 

M/M 

M/M 

built-in 

0 

M/M 

0/0 

external 

0 

O/M 

0/0 

content-identifier 

0 

O/M 

0/0 

content-length 

0 

M/M 

0/0 

per-message- indicators 

0 

M/M 

O/M 

disclosure-of -recipients 

0 

0/0 

0/0 

implicit-conversion-prohibited 

0 

M/M 

O/M 

alternate-recipient-allowed 

0 

M/M 

0/0 

content-return-request 

0 

0/0 

0/0 

per-domain-bi lateral- 

information 

0 

0/0 

0/0 

PerDomainBilaterallnfo 
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Table  32  -  Classification  of  the  PI  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    4  of  9 

Support  by  MT  Kernel 

Class 

Comment  s /Re  ferences 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

trace-information 

M 

M/M 

M/M 

Traceinf ormat  ion 

extensions 

0 

M/M 

M/M 

ExtensionField 

recipient-reassignment- 

prohibited 

0 

0/0 

0/0 

dl-expans ion-prohibited 

0 

M/M 

O/M 

conversion-with-loss- 

prohibited 

0 

0/0 

0/0 

originator-certificate 

0 

0/0 

0/0 

message-security-label 

0 

0/0 

0/0 

content-correlator 

0 

0/0 

0/0 

pr obe-or  i  g  i  n-au t hent  i  ca t  i  on- 

check 

0 

0/0 

0/0 

1      Yn;^  n  Q  "i  on  hiQl"nT*v 

n 

V-/ 

O/M 

O/M 

DLExpansionHi story 

internal-trace-information 

0 

M/M 

M/M 

InternalTraceInf o 

per-recipient-f ields 

M 

M/M 

M/M 

recipient-name 

M 

M/M 

M/M 

ORName 

originally-specif ied- 

recipient-number 

M 

M/M 

M/M 

per-recipient-indicators 

M 

M/M 

M/M 

j,  explicit-conversion 

0 

0/0 

0/0 

extensions 

0 

O/M 

O/M 

ExtensionField 

or iginator-requested- 

alternate-recipient 

0 

0/0 

0/0 

requested-deli very-method 

0 

M/M 

O/M 

physical-rendition-attributes 

0 

0/0 

0/0 

redirection-history 

0 

O/M 

O/M 

ReportTransf erEnvelope 

report-identifier 

M 

M/M 

M/M 

MTSIdentif ier 

report-destination-neune 

M 

M/M 

M/M 

ORName 

trace-information 

M 

M/M 

M/M 

Traceinf ormat ion 

extensions 

0 

M/M 

M/M 

ExtensionField 

message-security-label 

0 

0/0 

0/0 

or  i  a  inator— and— DL— exoans  ion— 

Or  i  g  i  nator AndDL 

history 

0 

M/M 

0/0 

ExpansionHi story 

r epor  t  i  ng-DL-name 

0 

0/0 

0/0 

reporting-MTA-certif icate 

0 

0/0 

0/0 

report-origin-authentication- 

check 

0 

0/0 

0/0 

internal-trace-information 

0 

M/M 

M/M 

InternalTraceInf o 

ReportTransf erContent 

subject-identifier 

M 

M/M 

M/M 

MTSIdentif ier 

sub ject- intermediate-trace- 

information 

0 

M/M 

M/M 

Traceinf ormat ion 

or iginal-encoded-informat ion- 

types 

0 

M/M 

M/M 

Encodedinf ormat ionTypes 
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Table  32  -  Classification  of  the  PI  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part     5  of  9 

Support  by  MT  Kernel 

Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  i 

content-type 

0 

M/M 

M/M 

built-in 

0 

M/M 

M/M 

external 

0 

M/M 

M/M 

content-identifier 

0 

M/M 

M/M 

returned-content 

0 

0/M 

0/0 

addi  t  ional-inf ormat  ion 

0 

0/0 

0/0 

extensions 

0 

0/M 

0/M 

ExtensionField 

content-correlator 

0 

0/M 

0/M 

per-recipient-f ields 

M 

M/M 

M/M 

actual-recipient-name 

M 

M/M 

M/M 

ORName 

or iginally-specif ied- 

recipient-number 

M 

M/M 

M/M 

per-recipient-indicators 

M 

M/M 

M/M 

last-trace-information 

M 

M/M 

M/M 

arrival-time 

M 

M/M 

M/M 

conve  r  t  ed-encoded- 

inf ormat  ion-types 

0 

M/M 

M/M 

Encodedinf ormat lonTypes 

report 

M 

M/M 

M/M 

delivery 

0 

M/M 

0/0 

message— del i very— t  ime 

u 

M/M 

TUT  /TUT 
M/M 

type-of-MTS-user 

0 

M/M 

0/0 

non-delivery 

0 

M/M 

M/M 

non-delivery-reason-code 

0 

M/M 

M/M 

non-delivery-diagnostic- 

code 

0 

0/M 

0/M 

originally- intended-recipient- 

name 

0 

M/M 

M/M 

UKName 

suppiement^ary— inrorma  t  ion 

u 

U/U 

U/  U 

extensions 

0 

M/M 

M/M 

ExtensionField 

redirection-history 

0 

M/M 

M/M 

Red irectionHi story 

physical-forwar ding-address 

0 

0/0 

0/0 

recipient-certificate 

0 

0/0 

0/0 

proof -of -deli very 

0 

0/0 

0/0 

Common  Data  Types 

Encodedinf ormat  ionTypes 

built-in-encoded-inf ormat ion- 

types 

M 

M/M 

M/M 

See  Note  3 

non-bas  i  c-par ameter s 

0 

0/0 

0/0 

external-encoded-inf ormat ion- 

types 

0 

0/M 

0/M 

MTSIdentif ier 

global-domain-identifier 

M 

M/M 

M/M 

GlobalDomainldentif ier 

local-identifier 

M 

M/M 

M/M 
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Table  32  -  Classification  of  the  Pi  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part    6  of  9 

Support  by  MT  Kernel 

Class 

Comments/References 

B/C 

A 

Protocol  Element 

s 

0/R 

0/R 

See  Note  1 

PerDomainBi lateralinf o 

count  ry— name 

n 

uf  /\jr 

M/M 

M/M 

admini  st  rat  ion— domain— name 

O 

ur  /uf 

M/M 

TUT  /Ut 

M/M 

DomainName 

private— domain— identifier 

U 

TUT  /TUT 
M/  M 

M/  M 

DomainName 

(only  encoded  as  SEQ  if 

both  present ) 

bi lateral— information 

M 

M/M 

M/M 

Tracelnformation 

Traceinf ormat  ionElement 

M 

M/M 

M/M 

global— domain— identifier 

M 

M/M 

M/M 

GlobalDomainldentif ier 

domain— suppl ied—inf ormat  ion 

\A 

M 

M/  M 

TUT  /M 

M/M 

arrival— time 

TUT 

TUf  /tut 

M/M 

TUT  /TUT 
M/M 

routing-action 

M 

M/M 

M/M 

relayed 

O 

M/M 

M/M 

rerouted 

U 

r\  /tut 
U/M 

/TUT 

U/M 

attempted-domain 

0 

0/M 

0/M 

GlobalDomainldentif ier 

deferred-time 

0 

M/M 

M/M 

convert  6a— Biicouea— 

1  nr  ormax,  ion— types 

U 

u/ ri 

u/  n 

Encodedinf ormat ionTypes 

otner — act i ons 

u 

/TUT 

U/rl 

r\  /tut 
U/M 

redi  rected 

o 

/tut 
O/M 

U/M 

dl-operation 

0 

0/M 

0/M 

ExtensionField 

type 

M 

M/M 

M/M 

criticality 

0 

0/M 

0/M 

f or-submission 

0 

0/0 

0/0 

for-transfer 

0 

M/M 

M/M 

f or-delivery 

0 

M/M 

M/M 

value 

M 

M/M 

M/M 

DLExpans  i  onHi  story 

DLExpansion 

M 

M/M 

M/M 

ORAddressAndOpt  ionalDi  rectory 

Name 

M 

M/M 

M/M 

ORName 

d 1 -expans  i  on- 1  i  me 

M 

M/M 

M/M 
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Table  32  -  Classification  of  the  PI  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part     7  of  9 

Support  by  MT  Kernel 

Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

See  Note  1 

InternalTracelnformation 

InternalTracelnformationElement 

M 

M/M 

M/M 

global-domain-identifier 

M 

M/M 

M/M 

GlobalDomainldentif ier 

mta-name 

M 

M/M 

M/M 

mua— suppi.  1 6a— 1  nr  orma  L  ion 

n 

M  /M 

M  /M 

arrival-time 

M 

M/M 

M/M 

routing-action 

M 

M/M 

M/M 

relayed 

0 

M/M 

M/M 

r eroutea 

U 

r\  /fjr 
U/  rl 

U/ W 

attempted 

0 

mta 

0 

O/M 

O/M 

domain 

0 

0/M 

O/M 

GlobalDomainldentif ier 

deferred-time 

0 

O/M 

O/M 

conver ted-encoded-inf ormat  ion 

-types 

0 

O/M 

O/M 

Encodedinf ormat  ionTypes 

other-actions 

0 

O/M 

O/M 

n 
u 

n  /M 

dl-operation 

0 

O/M 

O/M 

Or iginatorAndDLExpansionHi story 

or iginator-or-dl-name 

M 

M/M 

M/M 

or  i  g  i  nat  ion-or-expans  ion-t  ime 

M 

M/M 

M/M 

RedirectionHi story 

Redirection 

M 

M/M 

M/M 

intended-recipient-name 

M 

M/M 

M/M 

ORAddressAndOptionalDi rectory 

Name 

M 

M/M 

M/M 

ORName 

redirect ion-t ime 

M 

M/M 

M/M 

redirection-reason 

M 

M/M 

M/M 

ORName 

address 

M 

M/M 

M/M 

standard— attributes 

M 

M/M 

M/M 

country-name 

0 

M/M 

O/M 

Count ryName 

administrati  on-doma  i  n-name 

0 

M/M 

O/M 

DomainName 

network-address 

0 

M/M 

O/M 

terminal-identifier 

0 

M/M 

O/M 

private-domain-name 

0 

M/M 

O/M 

DomainName 

organi  zat  ion-name 

0 

M/M 

O/M 

numeric-user-identifier 

0 

M/M 

O/M 

personal-name 

0 

M/M 

O/M 

surname 

M 

M/M 

O/M 

given-name 

0 

M/M 

O/M 

initials 

0 

M/M 

O/M 

See  Note  4 

generation-qualifier 

0 

M/M 

O/M 

organi  zat  ional-uni  t-names 

0 

M/M 

O/M 
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Table  32  -  Classification  of  the  Pi  protocol  elements  (continued) 


MTS  Transfer  Protocol  (PI) 

Part     8  of  9 

Support  by  MT  Kernel 

Class 

Comments/References 

B/C 

A 

Protocol  Element 

S 

0/R 

0/R 

see  Note  i 

Organi  zat  ionUni  tName 

M 

M/M 

0/M 

domain-defined-at tributes 

0 

M/M 

0/M 

Doma  i  nDe  finedAttribute 

M 

M/M 

0/M 

type 

M 

M/M 

M/M 

value 

M 

M/M 

M/M 

extension-attributes 

0 

0/M 

0/M 

Extens  ionAtt r  ibute 

common-name 

0 

0/M 

0/M 

telet ex-common-name 

0 

0/M 

0/M 

teletex-organi  zat  ion-name 

0 

M/M 

0/M 

teletex-personal-name 

0 

M/M 

0/M 

teletex-organi zat ional-unit- 

names 

0 

M/M 

0/M 

teletex-domain-def ined- 

attr ibutes 

0 

M/M 

0/M 

pds-name 

0 

0/M 

0/M 

physical-delivery-country- 

name 

0 

0/M 

0/M 

postal-code 

0 

0/M 

0/M 

physical-delivery-office-name 

0 

0/M 

0/M 

physical-delivery-office- 

number 

0 

0/M 

0/M 

extens  ion-OR-address- 

components 

0 

0/M 

0/M 

phys  i  cal-del i very-personal- 

name 

u 

U/  rl 

u/ w 

phys  i  cal-del ivery- 

organizati  on-name 

0 

0/M 

0/M 

extension-physical-delivery- 

address-components 

0 

0/M 

0/M 

unformatted-postal-address 

0 

0/M 

0/M 

street-address 

0 

0/M 

0/M 

post-office-box-address 

0 

0/M 

0/M 

poste-restante-address 

0 

0/M 

0/M 

unique— postal— name 

u 

r\  /\jr 

U/  M 

local-postal-attributes 

0 

0/M 

0/M 

extended-network-address 

0 

0/M 

0/M 

terminal-type 

0 

0/M 

0/M 

directory-name 

0 

0/0 

0/0 

Ext ens ionAt tribute 

extension-attribute-type 

M 

M/M 

M/M 

extension-attribute-value 

M 

M/M 

M/M 

GlobalDomainldentif ier 

country-name 

M 

M/M 

M/M 

Count ryName 

administrati  on-doma  i  n-name 

M 

M/M 

M/M 

DomainName 

private-domain-identifier 

0 

M/M 

0/M 

DomainName 
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Table  32  -  Classification  of  the  PI  protocol  elements  (concluded) 


MTS  Transfer  Protocol  (PI) 


Part    9  of 


Support  by  MT  Kernel  Class 


Protocol  Element 


B/C 
0/R 


A 
0/R 


Comments/References 


See  Note  1 


Count ryName 
xl21-dcc-code 
iso-3166-alpha2-code 

DomainName 
numeric 
printable 


0/M 
M/M 


0/M 
M/M 


0/M 
0/M 


0/M 
0/M 


Notes 

1  The  MT  Kernel  implementation  classes  are  defined  in 
clause  17.1. 

2  The  action  to  be  taken  on  receipt  of  null  MTABind 
authentication  is  that  an  implementation  must  understand  the 
semantics,  but  the  form  of  authentication  that  is  acceptable 
is  a  local  matter. 

3  An  implementation  is  only  required  to  generate  EITs  that 
correspond  to  the  body  parts  it  is  capable  of  generating. 

4  If  the  initials  component  of  personal-name  attribute  is  used, 
it  should  comprise  all  of  the  person's  initials  (including  the 
given  name)  except  the  person's  surname,  as  specified  in 
X.402/IS  10021-2. 

5  All  SO  services  may  be  provided  without  using  the  message  token, 
e.g.,  using  per-message  extensions. 

6  In  secure  messaging,  use  of  elements  within  the  message  token  is 
preferred  to  use  of  equivalent  elements  in  the  subject  message 
envelope.  A  security  policy  shall  define  which  other  elements 
are  dynamically  mandated  and  shall  define  which  message  security 
labels  are  used  for  security  context  checking. 

7  In  the  absence  of  any  specific  processing  requirements  for  a 
particular  element  in  the  Message  Transfer  or  Probe  Transfer, 
the  action  to  be  taken  is  simply  the  creation  of  the 
corresponding  element  in  the  Report  Transfer  and  is  subject  to 
constraints  specified  in  X.411. 
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A.2      Interpersonal  Messaging  Protocol  (P2) 


Table  33  -  Classification  of  the  P2  protocol  elements 


Interpersonal  Messaging  Protocol 

{P2) 

Part  1  of  3 

Support 

TIA 

Protocol  Element 

S 

Comment  s/Re  f  e  r  ences 

InformationOb ject 

ipm 

0 

M/M 

IPM 

ipn 

0 

M/M 

IPN  -  see  Note  4 

IPM 

heading 

M 

M/M 

this-IPM 

M 

M/M 

IPMIdentif ier 

originator 

0 

M/M 

ORDescriptor 

author i zing-users 

0 

0/M 

ORDescr iptor 

n 

M/M 

RecipientSpecif ier 

copy-recipients 

0 

M/M 

RecipientSpecif ier 

blind-copy-recipients 

0 

0/M 

RecipientSpecif ier 

replied-to-IPM 

0 

M/M 

IPMIdentif ier 

obsoleted-IPMs 

0 

0/M 

IPMIdentif ier 

related-IPMs 

0 

0/M 

IPMIdentif ier 

subject 

0 

M/M 

See  Note  1, 

8 

expiry-time 

0 

0/M 

reply-time 

0 

0/M 

reply-recipients 

0 

0/M 

ORDescriptor 

importance 

0 

0/M 

sensitivity 

0 

0/M 

auto-forwarded 

0 

0/M 

extensions 

0 

0/M 

HeadingExtension 

incomplete-copy 

0 

0/0 

languages 

0 

0/M 

body 

M 

M/M 

BodyPart 

IPN 

common-fields 

M 

M/M 

sub ject-ipm 

M 

M/M 

ipn-originator 

0 

M/M 

ORDescriptor 

ipm-prefer red-recipient 

0 

M/M 

ORDescriptor 

conve  r  s  i  on-e  its 

0 

0/M 

EncodedlnformationTypes 

non-receipt-fields 

0 

M/M 

See  Note  5 

non-receipt-reason 

M 

M/M 

discard-reason 

0 

M/M 

auto-forward-comment 

0 

0/M 

returned-ipm 

0 

0/0 

See  Note  2 

receipt-fields 

0 

0/M 

receipt-time 

M 

M/M 
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Table  33  -  Classification  of  the  P2  protocol  elements  (continued) 


Interpersonal  Messaging  Protocol 

(P2) 

Part  2  of  3 

Support 

by 

UA 

Protocol  Element 

S 

0/R 

Comments /References 

acknowledgment —mode 

0 

0/M 

suppl-receipt-info 

0 

0/0 

HeadingExtension 

type 

M 

M/M 

value 

M 

M/M 

IPMIdentif ier 

user 

0 

0/M 

user-relative-identifier 

M 

M/M 

ORDescriptor 

formal-name 

0 

0/M 

ORName  -  see  Note  3 

free-form-name 

0 

0/M 

See  Note  8 

telephone-number 

0 

0/M 

RecipientSpecif ier 

recipient 

M 

M/M 

ORDescriptor 

notification-requests 

0 

0/M 

reply-requested 

0 

0/M 

BodyPart 

ia5-text 

0 

M/M 

parameters 

M 

M/M 

repertoire 

0 

0/M 

See  Note  6 

data 

M 

M/M 

voice 

0 

* 

See  Note  7 

g3-facsimile 

0 

0/0 

parameters 

M 

M/M 

numbe  r -o  f -page  s 

0 

0/M 

non-bas  i  c-pa  r  eime  t  e  r  s 

0 

0/M 

data 

M 

M/M 

g4-classl 

0 

0/0 

teletex 

0 

O/M 

parameters 

M 

M/M 

number-of -pages 

0 

0/0 

telex-compatible 

0 

0/0 

non-basic-parameters 

0 

0/0 

data 

M 

M/M 

videotex 

0 

0/0 

parameters 

M 

M/M 

syntax 

0 

0/M 

data 

M 

M/M 

encrypted 

0 

* 

See  Note  7 
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December  1991  (Stable) 


Table  33  -  Classification  of  the  P2  protocol  elements  (concluded) 


Interpersonal  Messaging  Protocol  (P2) 


Part  3  of  3 


Protocol  Element 


Support  by 
UA 
0/R 


Commen  ts /References 


message 
parameters 
delivery-time 
delivery-envelope 

data 
mixed-mode 
bilaterally-defined 
nationally-defined 
externally-defined 

parameters 

data 

GeneralTextBodyPart 
ODA1984BodyPart 
IS06937BodyPart 
BilaterallyDef inedBodyPart 
US  AP  r  i  va  t  e  lyDe  f  i  nedBodyPa  r  t 


0/M 
M/M 
0/M 
0/M 

M/M 
0/0 
0/0 
0/0 
0/M 
M/M 
M/M 

0/M 
0/0 
0/0 
0/0 
0/0 


See  P3  OtherMessage 
Del iveryFi elds 


See  Note  10 


See  Note  9 


Notes 

1  The  ability  to  generate  the  maximum  size  subject  is  not 
required. 

2  May  only  be  included  if  specifically  requested  by  the 
originator . 

3  The  ORName  should  be  specified  wherever  possible. 

4  The  ability  to  generate  an  IPN  is  optional  in  the  case  of 
an  implementation  in  which  a  non-receipt  condition  cannot 
occur  and  receipt  notification  is  not  supported. 

5  The  ability  to  generate  non-receipt-fields  is  optional  in 
the  case  of  an  implementation  in  which  a  non-receipt 
condition  cannot  occur  (see  note  4). 

6  Only  the  IA5  repertoire  has  to  be  supported  for  an 
iaS-text  body  part  on  reception. 

7  The  definition  of  these  body  parts  is  for  further  study  in 
CCITT  and  ISO. 

8  Only  the  IA5  subset  of  the  T.61  character  repertoire  need 
be  generated.  All  T.61  characters  should  be  supported  on 
reception. 

9  If  General  Text  is  supported,  an  implementation's  PICS  must 
identify  which  character  repertoires  can  be  generated  on 
origination  and  supported  on  reception. 

10  Any  basic  body  part  type  that  is  supported  on  reception  as 
an  integer  encoding  must  also  be  supported  as  an  object 
identifier  encoding.     Support  for  all  other  externally 
defined  body  parts  is  optional. 


Editor's  Note  -  The  draft  text  note  regarding  the  meaning  of  "support"  on  reception  was  missing  from  the 
editing  instructions. 
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December  1991  (Stable) 


A.3      MTS  Access  Protocol  (P3) 

NOTE  -  The  support  classifications  for  the  UA,  MS  and  MTA  below  indicate  the  minimum  level  of  support 
required  by  implementations  conforming  to  these  Agreements,  and  should  not  be  misconstrued  as  a 
redefinition  of  any  of  the  MHS  application  contexts. 


Table  34  -  Classification  of  the  P3  protocol  elements 


MTS  Access  Protocol  (P3) 

Part    1  of  12 

Support  by: 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Protocol  Element 

S 

Comments /References 

Operations 

MTSBind 
MTSUnbind 

M 
M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 

MTSBind 

MSSE 

message-submission 
probe-submission 
cancel-deferred-delivery 
submission-control 

M 
M 
M 
M 

M/- 
0/- 
0/- 
-/M 

M/M 
M/M 
M/M 
M/M 

-/M 
-/M 
-/M 
0/- 

Mes  sageSubmi  ss  ion 
ProbeSubmission 
CancelDef err edDeli very 
Submi  s  s  i  onCont  r ol 

MDSE 

message-delivery 
report-delivery 

delivery-control 

M 
M 

M 

-/M 
-/M 

0/- 

M/M 
M/M 

0/- 

M/- 
M/- 

-/M 

MessageDelivery 
ReportDelivery 
See  Note  10 
DeliveryControl 

MASE 
register 

change-credentials 

(MTS  to  MTSuser) 
(MTSuser  to  MTS) 

M 

M 
M 

0/- 

-/M 
0/- 

M/M 

M/M 
M/M 

-/M 

0/- 
-/M 

Register 

ChangeCredentials 
ChangeCredentials 

Note  -    A  Message  Store  must 
operations  unaltered. 

pass  through  all  MSSE  and  MASE 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    2  of  12 

Support  by: 

UA 

MS 

MTA 

0/R 

0/R 

0/R 

Comments/Ref erences 

Arauments /Results 

MTS  to  MTS  User 

ARGUMENT 

X  11  X  C  X  Ck  U  V_/  1.  ~llC4lll^ 

M 

-/M 

-/M 

M/- 

MTC!— Til  cio  r 

1 1 X  O  ~  U  o  C  i. 

-/- 

-/- 

-/- 

MTA 

V-/ 

-/O 

-/M 

M/- 

isMessageStore 

-/- 

-/- 

-/- 

messages-waiting 

0 

-/O 

-/o 

0/- 

M 

-/M 

-/M 

M/- 

s 1 mp  X  6 

n 
u 

-/M 

-/M 

M/- 

c?  4-  T"  /^n  n 

n 

-/o 

-/o 

0/- 

o^Vwui.  J.  ^  y    v^v^ii u c A  u 

-/o 

-/o 

0/- 

X\l_iO  <<J  i— 1  X 

r  p  s  r>ond  p  r — namp 

M 

M/- 

M/- 

-/M 

o 

M/- 

M/- 

-/M 

MTA 

-/- 

-/- 

-/- 

ismpssaopstor^ 

0 

M/- 

M/- 

-/M 

inessaaes— wai  t  ina 

-/- 

-/- 

-/- 

rp>SDonde>  r— f  r  pdpnt  i  al  s 

M 

M/- 

M/- 

-/M 

O  X  ILl      X  ^ 

0 

M/- 

M/- 

-/M 

0 

0/- 

0/- 

-/O 

MTfiRi  nd 

MTS  User  to  MTS 

ARGUMENT 

i  ni  t  i  ator — name 

M 

M/- 

M/- 

-/M 

iTiTS— iit^pr 

All  X  ^  USwX 

0 

M/- 

M/- 

-/M 

ItiTA 

-/- 

-/- 

-/- 

isMessageStore 

0 

M/M 

M/- 

-/M 

messages-waiting 

-/- 

-/- 

-/- 

initiator-credentials 

M 

M/- 

M/- 

-/M 

simple 

0 

M/- 

M/- 

-/M 

strong 

0 

0/- 

0/- 

-/O 

security-context 

0 

0/- 

0/- 

-/o 

RESULT 

res  ponde  r -name 

M 

-/M 

-/M 

M/- 

mTS-user 

-/- 

-/- 

-/- 

mTA 

0 

-/M 

-/M 

M/- 

isMessageStore 

-/- 

-/- 

-/- 

messages-waiting 

0 

-/O 

-/o 

0/- 

responder-credentials 

M 

-/M 

-/M 

M/- 

simple 

0 

-/M 

-/M 

M/- 

strong 

0 

-/o 

-/o 

0/- 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     3  of  12 

Support  by: 

UA 

MS 

MTA 

o 

0/R 

0/R 

0/R 

Comments/References 

Mes  sageSubmi  s  s  i  on 

ARGUMENT 

envelope 

M 

M/- 

M/- 

-/M 

MessageSubmission 

Envelope 

content 

M 

M/- 

M/- 

-/M 

RESULT 

message-submission-identif ier 

M 

-/M 

-/M 

M/- 

MTSIdentif ier 

in^ G  c  a (*f .c  11  Hm i  ci  q  i  oti — +•  i  tha 

M 

-/M 

-/M 

content-identifier 

0 

-/M 

-/M 

M/- 

extensions 

0 

-/o 

-/O 

0/- 

originating-MTA-certif icate 

0 

-/O 

-/O 

0/- 

-/o 

-/O 

0/- 

ProbeSubmi ss ion 

ARGUMENT 

envelope 

M 

M/- 

M/- 

-/M 

ProbeSubmi ss ion 

Envelope 

RESULT 

probe-submission-identif ier 

M 

-/M 

-/M 

M/- 

MTSIdentif ier 

probe-submiss ion-time 

M 

-/M 

-/M 

M/- 

content-identifier 

0 

-/M 

-/M 

M/- 

CancelDef err edDeli very 

ARGUMENT 

message-submission-identif ier 

M 

M/- 

M/- 

-/M 

MTSIdentif ier 

Submi  s  s  ionCont  rol 

ARGUMENT 

controls 

M 

-/M 

-/M 

M/- 

See  Note  1 

restrict 

0 

-/M 

-/M 

0/- 

permissible-operations 

0 

-/M 

-/M 

0/- 

permissible-maximum-content- 

length 

0 

-/M 

-/W 

U/- 

permissible-lowest-priority 

0 

-/M 

-/M 

0/- 

permissible-security-context 

0 

-/o 

-/o 

0/- 

RESULT 

waiting 

M 

M/- 

M/- 

-/M 

See  Note  2 

waiting-operations 

0 

0/- 

0/- 

-/M 

waiting-messages 

0 

0/- 

0/- 

-/M 

waiting-content-types 

0 

0/- 

0/- 

-/M 

waiting-encoded-informat ion- 

types 

0 

0/- 

0/- 

-/M 

EncodedlnformationTypes 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    4  of  12 

Support  by: 

UA 

MS 

MTA 

Protocol  Element 

S 

O/R 

U/K 

U/R 

Comments/References 

MessageDel i very 

ARGUMENT 

envelope 

M 

-/M 

-/M 

M/- 

MessageDel iveryEnvelope 

content 

M 

-/M 

-/M 

M/- 

RESULT 

recipient-certificate 

0 

0/- 

0/- 

-/O 

proof-of-deli very 

0 

0/- 

0/- 

-/o 

Repor tDel i very 

ARGUMENT 

envelope 

M 

-/M 

-/M 

M/- 

ReportDeli veryEnvelope 

returned— content 

0 

-/M 

-/M 

0/- 

DeliveryControl 

ARGUMENT  > 

controls 

M 

M/- 

TUT  / 

M/  — 

/tut 

See  Note  3 

restrict 

0 

O/- 

O/- 

-/M 

permissible-operations 

0 

0/- 

0/- 

-/M 

permissible-maximum-content- 

length 

0 

0/- 

0/- 

-/M 

permiss  ible-lowest-pr ior  i  ty 

0 

0/- 

0/- 

-/M 

permiss  ible— content— types 

0 

0/- 

0/~ 

-/M 

permi  ss  ible-encoded— 

informat ion— types 

0 

0/- 

0/- 

-/M 

Encodedinf ormat  ionTypes 

permissible-security-context 

0 

0/- 

0/- 

-/o 

RESULT 

waiting 

M 

— /M 

— /M 

Tur  / 

w/— 

See  Note  4 

wa  i  t  i  ng— ope  rati  ons 

0 

-/M 

-/M 

0/- 

wa  i  t  i  ng-me  s  s  ages 

0 

— /M 

-/M 

0/- 

wai  t  ing-content-types 

0 

-/M 

-/M 

0/- 

wai  t  ing-encoded-informat  ion- 

types 

0 

-/M 

-/M 

0/- 

Encodedinf ormat  ionTypes 

Register 

See  Note  5 

ARGUMENT 

user-name 

0 

0/- 

0/- 

-/o 

See  X.411,  8.4.1.1.1.1 

user-address 

0 

0/- 

0/- 

-/o 

deliverable-encoded- 

informat ion-types 

0 

0/- 

M/- 

-/M 

Encodedinf ormat  ionTypes 

deliverable-maximum-content- 

length 

0 

0/- 

M/- 

-/M 

default-delivery-controls 

0 

0/- 

0/- 

-/M 

restrict 

0 

0/- 

0/- 

-/M 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part    5  of  12 

Support  by: 

TTa 

MC 

i  i  X  t\ 

Protocol  Element 

s 

n  /D 
\j/  )\ 

U/K 

U/  K 

^^onuuen  t  s  /  Ke  r  e  r  enc  e  s 

permissible-operations 

0 

0/- 

0/- 

-/M 

permissible-maximum-content- 

length 

0 

O/- 

O/- 

/vr 
-/M 

permissible-lowest-priority 

0 

O/- 

O/- 

-/M 

permi  ss  ible-content-types 

0 

n/- 

n/- 

-/M 

permissible-encoded- 

informat  ion-types 

0 

n  / 
U/- 

U/- 

-/M 

ftiicoueainEoriuar  i  oni  yp6s 

deli ver able— content— types 

u 

n/ 
u/- 

/M 

labels-and-redirections 

0 

0/- 

0/- 

-/o 

user-security-label 

0 

0/- 

0/- 

-/o 

recipient-assigned-alternate- 

recipient 

0 

n  / 
U/- 

U/- 

-/U 

ChangeCredentials 

1  i  J.  D    C  v->   i*i  JL  O  U  o  I. 

ARGUMENT 

old-credentials 

M 

NOt  6  O 

simple 

0 

_  /M 

_  /M 

u/  — 

strong 

0 

-/o 

-/o 

0/- 

new-credentials 

M 

-/M 

-/M 

M/- 

Note  8 

simple 

0 

-/M 

-/M 

0/- 

strong 

0 

-/n 

-/O 

O/- 

ChangeCr edent  i  als 

ARGUMENT 

old-credentials 

M 

M/- 

— /  n 

s  imple 

0 

O/- 

O/- 

—  /M 

strong 

0 

n/- 

n/- 
u/  — 

-/n 
— /  u 

new-credentials 

M 

M  / 

simple 

0 

n/- 

n/- 

—  /M 

strong 

0 

u/  - 

n  / 
u/  - 

/n 
-/u 

MessageSubmissionEnvelope 

See  Note  6 

originator-name 

M 

M/- 

M/- 

-/M 

ORName 

or iginal-encoded-informat ion- 

types 

0 

M/- 

M/- 

-/M 

EncodedlnformationTypes 

content-type 

M 

M/- 

M/- 

-/M 

built-in 

0 

0/- 

M/- 

-/M 

external 

0 

0/- 

M/- 

-/M 

content-identif ier 

0 

0/- 

M/- 

-/M 

priority 

0 

M/- 

M/- 

-/M 

All  values 

per-message-indicators 

0 

M/- 

M/- 

-/M 

disclosure-of -recipients 

0 

0/- 

M/- 

-/M 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     6  of  12 

Support  by: 

TTTV 
UA 

Mb 

Turin  7\ 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/References 

implicit-conversion-prohibited 

0 

M/- 

M/- 

-/M 

alternate-recipient-allowed 

0 

M/- 

M/- 

-/M 

content-ret urn- request 

0 

U/- 

TVT  / 

M/- 

-/M 

deferred-deli very- time 

0 

M/- 

M/— 

-/M 

extensions 

0 

M/- 

M/- 

/TUT 

-/M 

recipient- reassignment- 

prohibited 

0 

0/- 

M/- 

-/M 

dl-expans ion-prohibited 

0 

M/- 

M/- 

-/M 

conversion-wi th-loss- 

prohibi  ted 

0 

0/- 

M/- 

/n/r 
-/M 

latest-deli very- time 

0 

0/- 

M/- 

-/M 

or igina tor— return— address 

0 

0/- 

M/- 

-/M 

originator-certificate 

0 

0/- 

0/- 

-/O 

content -conf  i  dent  i  al i  ty- 

algorithm— identifier 

0 

Of- 

0/- 

-/O 

message-or igin- 

authent  i  cat  ion-check 

0 

0/- 

0/- 

-/O 

message-security-label 

0 

0/- 

0/- 

-/O 

proof -of -submission-request 

0 

0/- 

0/- 

-/o 

content-correlator 

0 

0/- 

M/  — 

/TUT 
— /M 

forwarding-request 

0 

0/- 

0/- 

/TUT 
— /M 

MS  Abstract  Service  only 

PerRecipientMessageSubmission 

Fields 

M 

TUT  / 

M/  — 

TUT  / 

M/  — 

/TUT 
— /M 

recipient -name 

M 

M/  — 

M/- 

-/M 

ORName 

originator-report-request 

M 

M/  — 

M/  — 

— /M 

explicit-conversion 

0 

o  / 
0/- 

TUT  / 

M/  — 

—/ M 

extensions 

0 

TUT  / 

M/- 

-/M 

or iginator-requested- 

alternate-recipient 

0 

0/- 

0/- 

-/O 

requested-deli very-method 

0 

M/  — 

M/  — 

— /M 

Note  9 

phys ical-f orwarding- 

prohibited 

0 

0/- 

M/- 

-/M 

physical-f orwarding-address- 

'"  request 

0 

0/- 

0/- 

-/o 

physical-delivery-modes 

0 

0/- 

0/- 

-/o 

registered-mail-type 

0 

0/- 

0/- 

-/o 

recipient-number-f or-advice 

0 

0/- 

0/- 

-/o 

physical-rendition-attributes 

0 

0/- 

0/- 

-/o 

physical-delivery-report- 

request 

0 

0/- 

0/- 

-/o 

message-token 

0 

0/- 

0/- 

-/o 

content-integrity-check 

0 

0/- 

0/- 

-/o 

proof-of-deli very-request 

0 

0/- 

0/- 

-/o 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     7  of  12 

Support  by: 

no 

rl± 

Protocol  Element 

o 
o 

U/  K 

n  /D 

U/  K 

(~»  /d 
U/K 

i^omment  s/Kerer  ences 

XTLOlJcOUDini  SS  10Ili-jriV6X0p6 

Dee  wote  o 

M 

n/- 

M/ 

n/- 

-/n 

LfKlNaJne 

or  iginal— encoded— inf or mat  ion— 

\j 

M/- 

M/- 
ra/  — 

-/M 
— /ra 

"Pnoo/lo/^    T n ^ o K Tn 5* 4"  i  onT'TZTNOG 
iijii%^\^tieu   X 11 X  \^x  uia  t  x  v^ii  x  y  ^e  a 

content —type 

n 

M  / 
M/- 

M  / 
M/- 

/M 

UUi.  J-  t  —  Xii 

r\ 

o/- 

M/- 

— /M 
—/II 

ex t ernax 

yj 

n/_ 
u/  — 

ra/  — 

_  /M 

— /n 

cont ent — 1 uent i r i er 

ri 

u 

O/- 

M/- 
I'l/  — 

—  /M 
— / 1»1 

n 
\j 

M/- 

M  /_ 
ra/  — 

— /ra 

per— message— mui Cat or s 

(J 

n/- 

n/- 

/M 

-/n 

X iii^x  1.  w  1  t  —  v^v^ii  V e  1. 9  i.  wii  pi-      J.  u  X  t  eu 

n 

\J 

M/- 

M/- 
n/  — 

—  /M 
— /fl 

ax ternate— reel px ent— axxoweu 

n 

M  / 

/tut 

n 

M/- 

M/- 
n/  — 

— /ra 

xek^x^xeiiu    x  eaoo  x  y  ixuieii  t 

^x  (^11 X  jj  X  t  eu 

O/- 

M/— 
11/  — 

—  /M 
— / 11 

ux— t^A^aii^  X v^ii— ^ X  v^ii X 1^ X  t eu 

M/_ 

M/- 
n/  — 

— /ra 

v." wii V e X  9  X  wii— w X  til— x\«/&o  — 

^  X  v_/l  1 X  L;  X  t  e  U 

O/- 

M/- 
11/  — 

—  /M 
— /  ri 

originator-certificate 

0 

O/- 

n/- 
u/  — 

-/n 

— /  u 

message-security-label 

0 

n/- 
u/  — 

n/- 

U/  — 

_  /n 
— /u 

i.,c;i.i.t— v^wx  X\^xatwx 

n 

0/- 

M/- 

-/M 

^x  \jL)Ki — \j L  X  y  X 11— au t iieiit  x  v^'d t  x  \jii— 

oH  oo  V 

rt 
\J 

O/- 

0/- 

-/O 
— /  w 

It  e  X  £\ev«'  -L  p  -L  eii  t  It  X  L/jjeouDiux  s  s  x  on 

F"!  p1 

X  X  C  X  U  A 

M 

M  /_ 

M/- 
ra/  — 

—  /M 
— /ra 

T"  A o  T  TN  1  An        n  a  tti  a 

X  etrX^xeiit  — iialue 

M 

in/  — 

M  /_ 
n/  — 

_  /M 

— /ra 

^fxiNaiuc 

wx  xyxiiaLv.,/x— xc: ^^.^x  t  —  x iiea  t 

11 

M/- 
11/  — 

M/- 
11/  — 

—  /M 
—/II 

explicit-conversion 

0 

u/  — 

M  /_ 

n/  — 

_  /M 
— /ra 

extensions 

0 

M/- 
11/  — 

M/- 
11/  — 

—  /M 
— /  I'l 

originator-requested- 

alternate-recipient 

0 

0/- 

0/- 

-/o 

requested-deli very-method 

0 

M/- 

M/- 

-/M 

See  Note  9 

physical-rendition-attributes 

0 

0/- 

M/- 

-/M 

MessageDeliveryEnvelope 

See  Note  7 

message-delivery-identifier 

M 

-/M 

-/M 

M/- 

MTSIdentif ier 

message-delivery-time 

M 

-/M 

-/M 

M/- 

other-fields 

M 

-/M 

-/M 

M/- 

content-type 

M 

-/M 

-/M 

M/- 

built-in 

0 

-/M 

-/M 

M/- 

external 

0 

-/M 

-/M 

M/- 

originator-name 

M 

-/M 

-/M 

M/- 

ORName 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     8  of  12 

Support  by: 

UA 

MS 

MTA 

Protocol  Element 

s 

0/R 

0/R 

0/R 

Comments/Ref erences 

or  iginal— encoded— informat  ion— 

0 

-/M 

-/M 

M/- 

EncodedlnformationTypes 

prior  i  ty 

0 

-/M 

-/M 

M/- 

All  values 

del i very— flags 

0 

-/M 

-/M 

M/- 

implici  t— conversion— 

o  r  oh  i  b  i  t  p  d 

0 

-/M 

-/M 

M/- 

oth  AT  —  rpc  i  r>i  pnt"  — nainpg 

0 

-/M 

-/M 

M/- 

ORName 

thi  s— recipi  ent— name 

M 

-/M 

-/M 

M/- 

ORName 

or  iginally— intended— recipient — 

name 

0 

-/M 

-/M 

M/- 

ORName 

convsr ted— sncoded— informat  i  on— 

types 

0 

-/M 

-/M 

M/- 

EncodedlnformationTypes 

message— submi  ss  ion— time 

M 

-/M 

-/M 

M/- 

content-i  dent  i  f  i  er 

0 

-/M 

-/M 

M/- 

extens  ions 

0 

-/M 

-/M 

M/- 

conver s  ion— wi  th— loss— 

prohibi  ted 

0 

-/M 

-/M 

M/- 

requested— del i very— method 

0 

-/M 

-/M 

M/- 

See  Note  9 

phys  ical—forwar ding- 

prohibited 

0 

-/- 

-/- 

M/- 

physical-forwar ding-address- 

request 

0 

-/- 

TUT  / 

M/  — 

physical-del i very-modes 

0 

-/- 

-/- 

M/- 

0-16 

registered-mai 1-type 

0 

-/- 

-/- 

M/- 

0-256 

recipient-number-f or-advice 

0 

-/- 

-/- 

M/- 

1-32 

physical -rendition-attributes 

0 

-/- 

-/- 

M/- 

physical-delivery-report- 

request 

0 

-/- 

-/- 

M/- 

0-256 

originator-return-address 

0 

-/- 

-/- 

M/- 

originator-certificate 

0 

-/o 

-/o 

0/- 

message-token 

0 

-/o 

-/o 

0/- 

content-confidentiality- 

algorithm-identifier 

0 

-/o 

-/o 

0/- 

content- integrity-check 

0 

-/o 

-/o 

0/- 

message-origin- 

authent  i cat  ion-check 

0 

-/o 

-/o 

0/- 

message-security-label 

0 

-/o 

-/o 

0/- 

proof -of -deli very-request 

0 

-/o 

-/o 

0/- 

redirection-history 

0 

-/M 

-/M 

M/- 

dl-expans ion-history 

0 

-/M 

-/M 

M/- 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part     9  of  12 

Support  by: 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/References 

ReportDel 1 veryEnvelope 

See  Note  7 

sub ject— submission— identifier 

M 

-/M 

-/M 

M/- 

MTSIdentif ier 

content-identifier 

0 

-/M 

-/M 

M/- 

content- type 

0 

-/M 

-/M 

M/- 

bui It-in 

0 

-/M 

-/M 

M/- 

external 

0 

-/M 

-/M 

M/- 

or iginal-encoded-informat ion- 

types 

0 

-/M 

-/M 

M/- 

Encodedinf ormationTypes 

extens  ions 

o 

-/M 

-/M 

M/- 

message-secur  i  ty-label 

0 

-/o 

-/o 

0/- 

content-correlator 

0 

-/M 

-/M 

M/- 

or iginator-and-DL-expans ion- 

OriginatorAndDL 

history 

0 

-/M 

-/M 

M/- 

ExpansionHi story 

report  ing-DL-name 

0 

-/M 

-/M 

M/- 

report ing-MTA-certificate 

0 

-/o 

-/o 

0/- 

report-ori gin-authentication- 

check 

0 

-/o 

-/o 

0/- 

PerReci pi entReportDeli very- 

Fields 

M 

-/M 

-/M 

M/- 

actual-recipient-ncune 

M 

-/M 

-/M 

M/- 

ORName 

report 

M 

-/M 

-/M 

M/- 

del i very 

U 

-/M 

-/M 

M/- 

message-del i very- time 

M 

-/M 

-/M 

M/- 

type-of-MTS-user 

0 

-/M 

-/M 

M/- 

non-delivery 

0 

-/M 

-/M 

M/- 

non-del i very-reason-code 

M 

— /n 

_  /M 

non-del i very-diagnostic-code 

0 

-/M 

-/M 

M/- 

converted— encoded— informat  ion- 

types 

0 

-/M 

-/M 

M/- 

Encodedinf ormationTypes 

or iginally— intended— recipient- 

name 

0 

-/M 

-/M 

M/- 

ORName 

supplementary-information 

0 

-/M 

-/M 

M/- 

extensions 

0 

-/M 

-/M 

M/- 

redirection-history 

0 

-/M 

-/M 

M/- 

RedirectionHi story 

physical-forwar ding-address 

0 

-/M 

-/M 

M/- 

recipient-certificate 

0 

-/o 

-/o 

0/- 

proof -of -deli very 

0 

-/o 

-/o 

0/- 

ORName 

MTS  User  to  MTS 

standard-attributes 

country-name 

0 

M/- 

M/- 

-/M 

Count ryName 

administrati  on-doma  i  n-name 

0 

M/- 

M/- 

-/M 

DomainName 

network-address 

0 

M/- 

M/- 

-/M 

terminal-identifier 

0 

M/- 

M/- 

-/M 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part  10  of  12 

Support  by: 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/Ref erences 

pr  i  vat  e-doma  i  n-naune 

0 

M/- 

M/- 

-/M 

DomainName 

organi  zat  ion-name 

0 

M/- 

M/- 

-/M 

numeric-user-identifier 

0 

M/- 

M/- 

-/M 

personal-name 

0 

M/- 

M/- 

-/M 

surname 

M 

M/- 

M/- 

-/M 

!,  given-name 

0 

M/- 

M/- 

-/M 

initials 

0 

M/- 

M/- 

-/M 

generation-qualifier 

0 

M/- 

M/- 

-/M 

organizational-unit-names 

0 

M/- 

M/- 

-/M 

Organi zat ionUnitName 

M 

M/- 

M/- 

-/M 

domain-defined-at tributes 

0 

M/- 

M/- 

-/M 

Doma  i  nDe  f  i  nedAt  t  r  i  bu t  e 

M 

M/- 

M/- 

-/M 

type 

M 

M/- 

M/- 

-/M 

value 

M 

M/- 

M/- 

-/M 

extension-attributes 

0 

M/- 

M/- 

-/M 

ExtensionAt tribute 

common-name 

0 

M/- 

M/- 

-/M 

telet ex-common-name 

0 

0/- 

0/- 

-/M 

teletex-organi zat ion-name 

0 

0/- 

0/- 

-/M 

teletex-personal-name 

0 

0/- 

0/- 

-/M 

teletex-organi zat ional-unit- 

names 

0 

0/- 

0/- 

-/M 

telet ex-domain-defined- 

attr ibutes 

0 

0/- 

0/- 

-/M 

pds-name 

0 

0/- 

0/- 

-/M 

phys  i  cal-del i  very-count  ry-name 

0 

0/- 

0/- 

-/M 

postal-code 

0 

0/- 

0/- 

-/M 

physical-delivery-office-name 

0 

0/- 

0/- 

-/M 

physical-delivery-office- 

number 

0 

0/- 

0/- 

-/M 

extension-OR-address- 

components 

0 

0/- 

0/- 

-/M 

phys  ical— del i very— personal- 

name 

0 

0/- 

0/- 

-/M 

phys i cal-del ivery- 

organi  zat  ion-name 

0 

0/- 

0/- 

-/M 

extension-physical-delivery- 

address-components 

0 

0/- 

0/- 

-/M 

unformatted-postal-address 

0 

0/- 

0/- 

/TUT 
— /M 

street-address 

0 

0/- 

0/- 

-/M 

pos  t-of  f  i  ce-box-address 

0 

0/- 

0/- 

-/M 

poste-r est ante-address 

0 

0/- 

0/- 

-/M 

unique-postal-name 

0 

0/- 

0/- 

-/M 

local-postal-attributes 

0 

0/- 

0/- 

-/M 

extended-network-address 

0 

0/- 

0/- 

-/M 

terminal-type 

0 

0/- 

0/- 

-/M 

ORName 

MTS  to  MTS  User 

standard-attributes 

country-name 

0 

-/M 

-/M 

M/- 

Count ryName 
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Table  34  -  Classification  of  the  P3  protocol  elements  (continued) 


MTS  Access  Protocol  (P3) 

Part  11  of  12 

Support  by: 

UA 

MS 

MTA 

Protocol  Element 

S 

0/R 

0/R 

0/R 

Comments/Ref erences 

administration-domain-name 

0 

-/M 

-/M 

M/- 

DomainName 

network-address 

0 

-/M 

-/M 

M/- 

terminal-identifier 

0 

-/M 

-/M 

M/- 

pr  i  vat e-doma  i  n-name 

0 

-/M 

-/M 

M/- 

DomainName 

organizati  on-name 

0 

-/M 

-/M 

M/- 

numeric-user-identifier 

0 

-/M 

-/M 

M/- 

personal -name 

0 

-/M 

-/M 

M/- 

surname 

M 

-/M 

-/M 

M/- 

given-name 

0 

-/M 

-/M 

M/- 

initials 

0 

-/M 

-/M 

M/- 

generation-qualifier 

0 

-/M 

-/M 

M/- 

organi  zat  ional-uni  t-names 

0 

-/M 

-/M 

M/- 

Organi  zat  ionUni  tName 

M 

-/M 

-/M 

M/- 

domain-defined-at tributes 

0 

-/M 

-/M 

M/- 

Doma  i  nDe  f  i  nedAt  t  r  i  bu  t  e 

M 

-/M 

-/M 

M/- 

type 

M 

-/M 

-/M 

M/- 

value 

M 

-/M 

-/M 

M/- 

extension-attr  ibutes 

0 

-/M 

-/M 

M/- 

Ex  t  ens  i  onAt  t  r  i  bu t  e 

common— name 

0 

-/M 

-/M 

M/- 

t  e  1  e  t  ex-common-neune 

0 

-/M 

-/M 

M/- 

t el et ex— organi zat  ion— name 

u 

-/M 

-/M 

M/- 

teletex— per sonal— name 

O 

-/M 

-/M 

M/- 

teletex— organi  zat  ional-uni  t— 

names 

0 

-/M 

-/M 

M/- 

teletex— domain— defined— 

attributes 

0 

-/M 

-/M 

M/- 

pds-name 

0 

-/o 

-/M 

M/- 

phy s  ical-deli  ve  r y-count  r y-name 

0 

-/o 

-/M 

M/- 

postal-code 

0 

-/o 

-/M 

M/- 

phys  i  cal-del i very-of f  i  ce-name 

0 

-/o 

-/M 

M/- 

phy s  ical-deli very-office- 

number 

0 

-/o 

-/M 

M/- 

extension-OR-address- 

component  s 

0 

-/o 

-/M 

M/- 

physical-delivery-personal- 

name 

0 

-/o 

-/M 

M/- 

phys ical-deli very- 

organizati  on-name 

0 

-/o 

-/M 

M/- 

extens  ion-phys  i  cal-del i very- 

address-components 

0 

-/o 

-/M 

M/- 

unformatted-postal-address 

0 

-/o 

-/M 

M/- 

street-address 

0 

-/o 

-/M 

M/- 

post-office-box-address 

0 

-/o 

-/M 

M/- 

poste-r est ante-address 

0 

-/O 

-/M 

M/- 

un  i  que-pos  t  al -name 

0 

-/o 

-/M 

M/- 

local-postal-attributes 

0 

-/o 

-/M 

M/- 

extended-network-address 

0 

-/o 

-/M 

M/- 

terminal-type 

0 

-/o 

-/M 

M/- 
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Table  34  -  Classification  of  the  P3  protocol  elements  (concluded) 


MTS  Access  Protocol  (P3) 


Part  12  of  12 


Support  by! 


Protocol  Element 


UA 
0/R 


MS 
0/R 


MTA 
0/R 


Comments/References 


Encodedinf ormat  ionTypes 
built-in-encoded-informat ion- 
types 

non-basic-parameters 
external-encoded-inf ormat ion- 
types 
MTSIdentif ier 
global-domain-identif ier 
local-identifier 
Or  i  g  i  nator AndDLExpans  ionHi  story 
or iginator-or-dl-name 
or  i  ginat  ion-or-expans  ion-t  ime 
Redirect ionHi story 
Redirection 
intended-recipient-ncime 
ORAddressAndOptionalDi rectory 
Name 

redirection-time 
redi  rect ion-reason 


M/M 

0/0 

0/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 
M/M 


M/M 
0/0 

0/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 
M/M 


M/M 
0/0 

M/0 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 

M/M 
M/M 
M/M 


See  Note  3 


GlobalDomainldentif ier 


ORName 


Notes 

1  The  MTS-user  may  interpret  any  restriction  as  simply  withhold 
*all'  submissions. 

2  No  explicit  action  needs  to  be  taken  by  the  MTA. 

3  The  MTA  may  interpret  any  restriction  as  simply  withhold  'all' 
deliveries . 

4  No  explicit  action  needs  to  be  taken  by  the  MTS-user. 

5  The  Register  operation  may  be  performed  locally  (see  X.411). 
Although  not  required  for  the  UA  for  conformance,  it  is 
considered  to  be  a  useful  service  and  support  is  recommended. 

6  The  action  to  be  taken  by  a  submitting  MTA  is  as  defined  in 
X.411  (ISO  10021-4).     In  the  absence  of  any  specific  processing 
requirements  for  a  particular  element  in  a  submission  envelope, 
the  action  to  be  taken  is  simply  the  faithful  mapping  of  such 
element  to  the  corresponding  element  of  the  appropriate  transfer 
envelope. 

7  The  action  to  be  taken  by  a  delivering  MTA  is  as  defined  in  X.41 
(ISO  10021-4).     In  the  absence  of  any  specific  processing 
requirements  for  a  particular  element  in  a  delivery  envelope,  the 
action  to  be  taken  is  simply  the  creation  of  such  element  from 
the  corresponding  element  of  the  appropriate  transfer  envelope. 

8  At  least  one  of  simple  and/or  strong  must  be  specified, 

9  Applies  to  ORNames  containing  Directory  Names  and/or  ORAddresses 
See  Recommendation  X.411,  section  8.2.1.1.1.14. 

10  In  the  absence  of  any  specific  processing  requirements  for  a 
particular  element  in  the  Message  Submission,  or  Probe  Submission, 
the  action  to  be  taken  is  simply  the  creation  of  the  corresponding 
element  in  the  ReportDelivery  (subject  to  any  constraints  specified 
in  X.411) . 

11  Applicable  only  to  reception  by  a  PDAU. 
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A.4      MS  Access  Protocol  (P7) 


Table  35  -  Classification  of  the  P7  protocol  elements 


MS  Access  Protocol  (P7) 

Part    1  of  6 

Support  by: 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Comments/References 

upe rat ions 

n.oi3inu 

Tur 

n 

M/- 

-/M 

MSBind 

r'lounDinci 

n 

M/- 

-/M 

message-submission 

M 

M/- 

-/M 

See  P3  MessageSubmission 

probe-submission 

M 

0/- 

-/M 

See  P3  ProbeSubmission 

cancel-deferred-delivery 

M 

u/- 

/M 

See  P3  CancelDef erred 

Delivery 

en  T^Trt  10  0  1  /^t**     j^/^y\  4*  t"/^  1 
SUlJllll  SSI  OIl~CQIlX^  LKJX 

M 

n 

-/M 

M/- 

See  P3  SubmissionControl 

MASE 

L 6y 1 S  c6L 

M 

0/- 

-/M 

See  P3  Register 

M 

-/M 

M/- 

See  P3  ChangeCredentials 

^iidiiy t^~v^  1  t;Lic;ii 1 1  cix 9    i              no  ^ 

M 

0/- 

-/M 

See  P3  ChangeCredentials 

mt?c;f 

en  TTiTn  a  t*  i  d 
o  U.11U11CI  L  1.  ^  C! 

M 

M/- 

-/M 

Summarize 

M 

Ik 

M/- 

-/M 

List 

M 

M/- 

-/M 

Fetch 

<^  1  ^  "h  ^ 

M 

1  X 

M/- 

-/M 

Delete 

register-ms 

M 

0/- 

-/M 

Register-MS 

alert 

M 

-/o 

0/- 

Alert 

Arguments/Results 

MSBind 

ARGUMENT 

MSBindArgument 

M 

M/- 

-/M 

initiator-name 

M 

M/- 

-/M 

initiator-credentials 

M 

M/- 

-/M 

simple 

0 

M/- 

-/M 

strong 

0 

0/- 

-/o 

security-context 

0 

0/- 

-/o 

fetch-restrictions 

0 

0/- 

-/M 

Opt'l  in  Basic  MS (Note  5) 

allowed-content-types 

0 

0/- 

-/M 

allowed-EITs 

0 

0/- 

-/M 

maximum-content-length 

0 

0/- 

-/M 

MS-configur at ion-request 

0 

0/- 

-/M 
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Table  35  -  Classification  of  the  P7  protocol  elements  (continued) 


MS  Access  Protocol  (P7) 

Part     2  of  6 

Support  by: 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Commpnt  s /Rp  f p  rpncps 

RESULT 

MSBindResult 

M 

-/M 

M/- 

responder-credentials 

M 

-/M 

M/- 

simple 

0 

-/M 

M/- 

X  X/ 

strong 

0 

-/O 

0/- 

avai lable-auto-actions 

0 

-/M 

M/- 

available-attribute-types 

0 

-/M 

M/- 

alert- indication 

0 

-/O 

0/- 

content-types-supported 

0 

-/M 

M/- 

Summar i  ze 

ARGUMENT 

Summar izeArgument 

M 

M/- 

-/M 

information-base-type 

0 

0/- 

-/M 

Inf ormat  ionBase 

selector 

M 

M/- 

-/M 

Selector 

o  Liiiuiici  1.  y     1-        u  V  0  u  o 

n 

w 

0/- 

-/M 

RESULT 

Summar izeResult 

M 

-/M 

M/- 

next 

0 

-/M 

M/- 

count 

M 

-/M 

M/- 

span 

0 

-/M 

M/- 

lowest 

M 

-/M 

M/- 

highest 

M 

-/M 

M/- 

summaries 

0 

-/M 

M/- 

absent 

0 

-/M 

M/- 

present 

0 

-/M 

M/- 

type 

M 

-/M 

/XX 

M/- 

value 

M 

-/M 

M/- 

^  count 

M 

-/M 

M/- 

List 

ARGUMENT 

ListArgument 

M 

M/- 

-/M 

information-base-type 

0 

0/- 

-/M 

Inf ormat ionBase 

selector 

M 

M/- 

-/M 

Selector 

requested-attributes 

0 

0/- 

-/M 

AttributeSelection 

RESULT 

ListResult 

M 

-/M 

M/- 

next 

0 

-/M 

M/- 

requested 

0 

-/M 

M/- 

Entryinf ormat ion 
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Table  35  -  Classification  of  the  P7  protocol  elements  (continued) 


MS  Access  Protocol  (P7) 

Part     3  of  6 

Support  by: 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Commen t  s /Re  f  e  r enc e s 

Fetch 

ARGUMENT 

FetchArgument 

M 

M/- 

-/M 

information-base-type 

0 

0/- 

-/M 

Inf ormat  i  onBase 

i  tern 

M 

M/- 

-/M 

search 

0 

M/- 

-/M 

Optional  in  Basic  MS 

precise 

0 

M/- 

-/M 

requested-at tributes 

0 

0/- 

-/M 

AttributeSelection 

RESULT 

FetchResult 

M 

-/M 

M/- 

entry-inf ormat ion 

0 

-/M 

M/- 

Entryinf ormat ion 

list 

0 

-/M 

M/- 

next 

0 

-/M 

M/- 

Delete 

ARGUMENT 

DeleteArgument 

M 

M/- 

-/M 

inf ormat ion- base— type 

U 

0/- 

-/o 

Inf ormat ionBase 

i  tems 

M 

M/- 

-/M 

selector 

0 

M/- 

-/M 

Optional  in  Basic  MS 

sequence— numbers 

o 

M/- 

-/M 

T3'E'C?TTT  rn 
RtbULT 

DeleteResult 

M 

-/M 

M/- 

Register— MS 

AKljUMil.NT 

Regi  St er— MS Argument 

M 

M/- 

-/M 

auto-action-registrations 

0 

0/- 

-/o 

type 

M 

M/- 

-/M 

registration- identifier 

0 

M/- 

-/M 

registration-parameter 

M 

M/- 

-/M 

See  auto  action 

registration  parameters 

auto-act ion-deregi St rat ions 

0 

0/- 

-/o 

type 

M 

M/- 

-/M 

registration-identifier 

0 

M/- 

-/M 

list-attribute-defaults 

0 

M/- 

-/M 

Optional  in  Basic  MS 

fetch-attribute-defaults 

0 

M/- 

-/M 

Optional  in  Basic  MS 

change-credentials 

0 

M/- 

-/M 

See  Note  1 

old-credentials 

M 

M/- 

-/M 

new-credentials 

M 

M/- 

-/M 

user-security-labels 

0 

0/- 

-/o 

RESULT 

Register-MSResult 

M 

-/M 

M/- 
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Table  35  -  Classification  of  the  P7  protocol  elements  (continued) 


MS  Access  Protocol  (P7) 

Part     4  of  6 

Support  by: 

UA 

MS 

Protocol  Element 

S 

0/R 

0/R 

Comments/References 

Alert 

ARGUMENT 

AlertArgument 

M 

-/M 

M/- 

alert-registration-identifier 

M 

-/M 

M/- 

new-entry 

0 

-/M 

M/- 

Entrylnformation 

RESULT 

AlertResult 

0 

M/- 

-/M 

Auto  Action  Registration 

Parameters 

AutoForwardRegistrationParameter 

filter 

0 

0/- 

-/M 

Filter 

auto-forward-arguments 

M 

M/- 

-/M 

originator-name 

M 

M/- 

-/M 

content-identifier 

0 

0/- 

-/M 

priority 

0 

0/- 

-/M 

per-message- indicators 

0 

0/- 

-/M 

See  P3  MessageSubmission 

-Envelope 

defer red— del i very— time 

0 

0/- 

-/M 

extensions 

0 

0/- 

-/M 

See  P3  MessageSubmission 

-Envelope 

per-recipient-f ields 

M 

M/- 

-/M 

recipient-name 

M 

M/- 

-/M 

originator-report-request 

M 

M/- 

-/M 

explicit-conversion 

0 

0/- 

-/M 

extensions 

0 

0/- 

-/M 

See  P3  MessageSubmission 

-Envelope 

delete-after-auto-forwarding 

0 

0/- 

-/M 

other-parameters 

0 

0/- 

/TUT 
—  /  M 

See  Note  2 

auto-forward ing-comment 

0 

0/- 

-/M 

cover-note 

0 

0/- 

-/M 

this-ipm-pref ix 

0 

0/- 

-/M 

AutoAlertRegistrationParameter 

filter 

0 

0/- 

-/M 

Filter 

alert-addresses 

0 

0/- 

-/O 

address 

M 

M/- 

-/M 

alert-qualifier 

0 

0/- 

-/o 

requested-attr ibutes 

0 

0/- 

-/M 

AttributeSelection 
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Table  35  -  Classification  of  the  P7  protocol  elements  (continued) 


MS  Access  Protocol  (P7) 

Part     5  of  6 

Support  by: 

UA 

U/R 

MS 

O/R 

Protocol  Element 

S 

Comments/References 

Common  Data  Types 

Att r  ibuteSelect  ion 
type 
from 
count 

M 
0 
0 

M/- 
O/- 
0/- 

-/M 
— /n 
-/M 

AttributeValueAssertion 
type 
value 

w 
M 

M/- 
M/- 

-/M 
-/M 

Entrylnformation 
sequence-number 
attributes 
type 
values 

M 
0 
M 
M 

-/M 
-/M 
-/M 
-/M 

M/- 
M/- 
M/- 
M/- 

Filter 
item 
and 
or 
not 

0 
0 
0 
0 

M/- 
M/- 
M/- 
M/- 

-/M 
-/M 
-/M 
-/M 

Filterltem 
See  Note  3 
See  Note  3 
See  Note  4 

equality 

substrings 
type 

initial 

any 

final 
greater-or-equal 
less-or-equal 
present 

approximate-match 

0 

0 
M 
M 
0 
0 
0 
0 
0 
0 
0 

M/- 

0/- 
M/- 
M/- 
0/- 
n/- 

U/  — 

0/- 
0/- 
0/- 
0/- 
0/- 

-/M 

-/o 

-/M 
-/M 
-/M 
— /n 
-/M 
-/M 
-/M 
-/M 

-/o 

AttributeValueAssertion 
(Support  is  Optional  if 
ORName ) 

AttributeValueAssertion 
AttributeValueAssertion 

Inf ormationBase 
stored-messages 
inlog 
out log 

0 
0 
0 

M/- 
0/- 
0/- 

-/M 

-/o 
-/o 
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Table  35  -  Classification  of  the  P7  protocol  elements  (concluded) 


MS  Access  Protocol  (P7) 

Part    6  of  6 

Support  by: 

UA 
0/R 

MS 
0/R 

Protocol  Element 

S 

Comments /References 

Range 

sequence-number-range 
from 
to 

0 
0 
0 

0/- 
0/- 
0/- 

-/M 
-/M 

-/M 

creation-time-range 
from 
to 

0 
0 
0 

0/- 
0/- 
0/- 

-/M 
-/M 
-/M 

Selector 
child-entries 
range 
filter 
limit 
override 

0 
0 
0 
0 
0 

0  s  o  o  o 

1  1  1  1  1 

-/M 
-/M 
-/M 
-/M 
-/M 

Range 
Filter 

Opt'l  in  Basic  MS-Note  5 

Notes 

1  At  least  one  of  simple  and/or  strong  must  be  specified. 

2  The  specified  syntax  of  other-parameters  is  context-specific 
-  see  X.413  section  12.1. 

3  For  recursive  use  of  filter,  only  support  of  the  "item"  and  the 
"not"  fields  is  required;  there  is  only  one  level  of  recursion. 

4  For  recursive  use  of  filter,  only  support  of  the  "item"  field 
is  required;  there  is  only  one  level  of  recursion. 

5  If  one  of  fetch-restrictions  of  MSBind  and  override  of  Selector 
is  implemented,  the  other  must  also  be  implemented. 
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December  1991  (Stable) 


A.5     Classification  of  the  PI  Protocol  Elements  for  Security  Classes 

The  protocol  element  classifications  used  in  tables  36  and  37  should  be  viewed  as  a  delta  to  the  lower 
security  class  or,  if  there  is  no  lower  security  class,  to  the  kernel  as  classified  in  table  33.  Thus,  table  36 
shows  the  additional  support  required  in  P1  to  conform  to  security  class  Si .  Table  37  indicates  the  additional 
support  required  to  support  security  class  S2  (above  and  beyond  that  for  security  class  Si). 


NOTES 


1  There  are  no  additional  classifications  for  security  class  SO. 


2  The  addition  of  mandatory  content  confidentiality  does  not  affect  the  PI  protocol. 


Table  36  -  Conformance  classification  of  the  PI  protocol  elements  for  security  class  SI 


MTS  Transfer  Protocol  (PI)  for  Security  Class  SI 


Part     1  of  2 


MT  Kernel  Static  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 

0/R 


Dyn 


Commen t s /Re f e r enc e s 


MTABind 
ARGUMENT 
<SET> 

initiator-credentials 
simple 
strong 
bind-token 
certificate 
secur  i  ty-context 
RESULT 
<SET> 

responder-credentials 
simple 
strong 
bind-token 
certificate 

MessageTransf erEnvelope 
extensions 
message-security-label 


0/0 
M/M 
M/M 
0/0 
M/M 


0/0 
M/M 
M/M 
0/0 


M/M 


0/0 
M/M 
M/M 
0/0 
M/M 


0/0 
M/M 
M/M 
0/0 


M/M 


M 
X 
M 
M 

M 


M 
X 
M 
M 


M 
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Table  36  -  Conformanct  classification  of  the  P1  protocol 

(concluded) 


December  1991  (Stable) 

elements  for  security  class  S1 


MTS  Transfer  Protocol  (PI)  for  Security  Class  SI 


MT  Kernel  Static  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 
0/R 


Dyn 


Part     2  of 


Comments/References 


ReportTransf erEnvelope 
ejttensions 

message-security-label 
per-rec i pi ent -fields 
extensions 
message- token 
asymmetric- token 
signed-data 

message-security-label 
encrypt ed-data 
message-security-label 

bind-token 
asymmetric- token 
signature-algorithm-identifier 
name 
time 

signed-data 

enc  ryption-algorit  hm- 
identifier 

encrypt ed-data 
message-security-label 
content- integrity-key 

message-security-label 
security-policy-identifier 


M/M 

0/0 

M/M 
M/M 


M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 

M/M 
M/M 


M/M 

0/0 

M/M 
M/M 


M/M 
M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 

M/M 
M/M 


See  Note  2 


M 


M 


See  Note  2 
See  Note  2 

See  Note  1 


M 
M 
M 
M 


M 
M 


See  Note  2 


Notes 

1  In  line  with  the  CCITT  MHS  Implementors '  Guide,  the  asymmetric 
token  can  be  used  by  symmetric  and  asymmetric  techniques  as 
identified  by  the  algorithm  identifier. 

2  The  message  security  label  may  appear  in  any  or  all  of  the 
indicated  locations  in  the  envelope.  However  the  Security  context 
service  applies  only  to  the  label  in  the  "extensions"  and/or  token 
signed-data  as  defined  by  the  security  policy  in  force.  Labels  in  th 
token  encrypted  data  have  only  end-to-end  (UA-to-UA)  significance. 
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Table  37  -  Conformance  classification  of  the  P1  protocol  elements  for  security  class  S2 


MTS  Transfer  Protocol  (PI)  for  Security  Class  S2 


Part    1  of 


MT  Kernel  Static  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 

0/R 


Dyn 


Comments/References 


MessageTransf erEnvelope 
extension 
originator-certificate 
certificate 
cer t  i  f  i cat  ion-path 
message-origin-authentication- 
check 

algorithm-identifier 
content 

content-identifier 
message-security-label 

ProbeTransf erEnvelope 
extensions 
originator-certificate 
certificate 
certification-path 
probe-origin-authentication- 
check 

algorithm-identifier 

content-identifier 

message-security-label 

ReportTransf erEnvelope 
extensions 
report ing-MTA-certificate 
certificate 
certification-path 
report-origin-authentication- 
check 

algorithm- identifier 

content-identifier 

message-security-label 
per-recipient 
actual-recipient-neime 
or iginally- intended-recipient- 
name 

delivery 
message-delivery-time 
type-of-MTS-user 
recipient-certificate 
proof -of -deli very 

non-delivery 
non-delivery-reason-code 
non-del i  ve  ry-d  i  agnos  t  i  c-code 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 
M/M 

0/0 
0/0 
M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
0/0 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 

M/M 
M/M 
M/M 
M/M 
M/M 
M/M 

0/0 
0/0 
M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
0/0 


M 


M 


M 


83 


Part  8:  Message  Handling  Systems 


December  1991  (Stable) 


Table  37  -  Conformance  classification  of  the  PI  protocol  elements  for  security  class  S2 

(concluded) 


MTS  Transfer  Protocol  (PI)  for  Security  Class  S2 


Part    2  of 


MT  Kernel  Static  Support  by  MTS  Class 


Protocol  Element 


B/C 
0/R 


A 
0/R 


Dyn 


Comments/References 


Certificate 
version 
ser ialNumber 
signature 

algorithm 

parameters 
issuer 
validity 

notBefore 

notAfter 
subject 

sub jectPublicKey Info 
algorithm 
sub jectPublicKey 


M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 


M/M 
M/M 
M/M 
M/M 
0/0 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
M/M 
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A.6      Classification  of  the  P3  Protocol  Elements  for  Security  Classes 

The  protocol  element  classifications  in  tables  38,  39,  and  40  should  be  viewed  as  a  delta  to  the  lower 
security  class  or,  if  there  is  no  lower  security  class,  to  the  kernel  as  classified  in  table  34.  Thus,  table  38 
shows  the  additional  support  required  in  P3  to  conform  to  security  class  SO.  Table  39  indicates  the  additional 
support  required  to  support  security  class  S1  (above  and  beyond  that  for  security  class  SO).  Table  40 
indicates  the  additional  support  required  to  support  security  class  S2  (above  and  beyond  that  for  security 
class  81). 

NOTE  -  There  are  no  dynamic  conformance  classifications  required  by  security  class  SO  (table  38). 


Table  38  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  SO 


MTS  Access  Protocol  (P3)  for  Security  Class  SO 

Part     1  of  2 

Static  Support  by: 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Dyn 

Comments/References 

Protocol  Element 

MessageDelivery 

RESULT 

proof-of-delivery 

M/- 

M/- 

-/o 

MessageSubmissionEnvel ope 

PerRecipientMessageSubmission 

Fields 

extensions 

message-token 

M/- 

M/- 

-/o 

asymmetric- token 

M/- 

M/- 

-/o 

signature-algorithm- 

identifier 

M/- 

M/- 

-/o 

name 

M/- 

M/- 

-/o 

time 

M/- 

M/- 

-/o 

signed-data 

M/- 

M/- 

-/o 

content-confidentiality- 

algorithm-identifier 

0/- 

0/- 

-/o 

content -integrity-check 

M/- 

M/- 

-/o 

See  Note  1 

message-security-label 

0/- 

0/- 

-/o 

proof -of -deli very-request 

M/- 

M/- 

-/o 

See  Note  1 

message-sequence-number 

0/- 

0/- 

-/o 

encrypt  i  on-algor  i  thm- 

identif ier 

0/- 

0/- 

-/o 

encrypted-data 

M/- 

M/- 

-/o 

content-confidentiality- 

key 

0/- 

0/- 

-/o 

content- integrity-check 

M/- 

M/- 

-/o 

See  Note  1 

message-security-label 

0/- 

0/- 

-/o 

content- integrity-key 

0/- 

0/- 

-/o 

message-sequence-number 

0/- 

0/- 

-/o 

content- integrity-check 

M/- 

M/- 

-/o 

See  Note  1 

proof -of -deli very-request 

M/- 

M/- 

-/o 

See  Note  1 
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Table  38  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  SO 

(concluded) 


MTS  Access  Protocol  (P3)  for  Security  Class  SO 

Part    2  of  2 

• 

Static  Support  by: 

UA 

MS 

MTA 

Protocol  Element 

O/R 

O/K 

O/R 

Dyn 

Comments /References 

ri6o  sa^cJj^x  1 V  G  L  y  11*11  V  G -LKjp^ 

other-fields 

extens  ions 

message- token 

-/M 

-/M 

0/- 

asymmet  r  i  c-token 

-/M 

-/M 

0/- 

s  ignature— algor i  thm— 

identifier 

-/M 

/if 

-/M 

0/- 

name 

-/M 

-/M 

0/- 

t  ime 

-/M 

-/M 

0/- 

signed-data 

-/M 

-/M 

0/- 

content— confidentiality- 

algorithm-  identifier 

-/O 

-/O 

0/- 

content -integr  i  ty-check 

-/M 

-/M 

0/- 

See  Note  i 

message-security-label 

-/o 

-/o 

0/- 

proof-of-delivery-request 

-/M 

-/M 

0/- 

See  Note  1 

message— seguence—number 

-/O 

-/O 

O/- 

encrypt  ion— algor i thm— 

identifier 

-/O 

0/- 

encrypted-data 

-/M 

-/M 

0/- 

content-confidentiality- 

key 

-/o 

-/o 

0/- 

content-integrity-check 

-/M 

/TljT 

-/M 

0/- 

See  Note  i 

message-security-label 

-/o 

-/O 

0/- 

content- integrity-key 

-/o 

-/o 

0/- 

message-sequence-number 

-/o 

-/o 

0/- 

content-integri ty-check 

-/M 

-/M 

0/- 

See  Note  1 

proof-of-delivery-request 

-/M 

-/M 

0/- 

See  Note  1 

ReportDeliveryEnvelope 

PerReci pi entReportDeli very- 

Fields 

extensions 

proof -of -deli very 

-/M 

-/o 

0/- 

Notes 

1    Implementations  shall  generate  no 

more  that  one  instance 

of  these 

identically-named  protocol  elements  in  a  single  message. 

i! 
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Table  39  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  S1 


MTS  Access  Protocol  (P3)  for  Security  Class  SI 

Part    1  of  3 

KJn 

WO 

n/R 

nxD   uo  wxo  user 

ARGUMENT 

initiator-credentials 

M 

s  1  nip  X  6 

-/u 

/n 
-/u 

n  / 
u/- 

Y 
A 

4"  T*  /~\T^  ^ 

s  X,  r  on^ 

-/n 

-/M 

M  / 

n/- 

n 

Dinu— uOKen 

-/n 

/M 

-/M 

M/- 

vr 

-/n 

-/n 

n/- 

-/M 

-/M 

M/- 

M 

DVQTTT  ^ 
M\J-i  O  U  Xj  1 

O  1  TTl  T~\  n  ^ 

o  i.  Ilipx 

yj/- 

/n 
-/u 

Y 
A 

4*  "r*  /*f 

s  L  rong 

-/  M 

ur 
n 

M/ 
M/- 

M/- 

/M 

vr 

n/- 
u/  — 

n/- 

-/n 
— /u 

MT'Q'R  T  n*^ 
irlX  tDij  1.  iiU 

ARGUMENT 

initiator-credentials 

M 

C  1  TTl      n  ^ 

n/ 
u/- 

n/ 
u/- 

/n 
-/u 

Y 
A 

f7  4-      /-\  /*f 

s  u  rung 

M/- 

M  / 
M/- 

/m 
-/M 

M 

D 1  IlCi  — tOKdl 

n/- 

M/- 

-/M 

certificate 

0/- 

0/- 

-/o 

security-context 

M/- 

M/- 

-/M 

M 

RESULT 

M 

-/u 

/n 
-/u 

n  / 
u/- 

Y 
A 

Strong 

-/M 

-/M 

M/- 

M 

bind-token 

-/M 

-/M 

M/- 

M 

-/O 

-/O 

0/- 

-/M 

M/M 

M/- 
li/  — 

controls 

permissible-security-context 

-/M 

-/M 

M/- 

DeliveryControl 

M/- 

M/- 

-/M 

ARGUMENT 

controls 

permissible-security-context 

M/- 

M/- 

-/M 

Register 

ARGUMENT 

user-name 

M/- 

M/- 

-/M 

labels-and-redirections 

user-security-label 

M/- 

M/- 

-/M 
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Table  39  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  S1  (continued) 


MTS  Access  Protocol  (P3)  for  Security  Class  SI 

Part     2  of  3 

Static  Support  by: 

UA 

O/R 

MO 

no 

O/K 

MIA 
O/K 

Dyn 

Comments/References 

Protocol  Element 

ChangeCredent  i  als 

MTS  to  MTSuser 

old— credentials 

M 

simple 

-/o 

-/o 

0/- 

X 

St  rong 

-/M 

/vr 
-/M 

vr  / 
M/- 

w 

rl 

Dina— toKen 

-/M 

/vr 

n 

cer t  i  f  icate 

-/O 

-/O 

o/- 

new— credent i als 

TUT 
M 

simple 

-/O 

-/O 

o/- 

A 

s  t  rong 

/M 
-/M 

-/M 

M  / 

M/- 

lur 

D 1 nu— tOKen 

-/M 

/M 
-/M 

M/- 

rl 

certificate 

_/0 

-/O 

0/- 

ChangeCredent i als 

MTSuser  to  MTS 

old-credentials 

M 

s  1  mp  J.  e 

r»  / 
U/- 

u/- 

/n 
-/u 

Y 
A 

strong 

M/- 

M/- 

-/M 

M 

bind— token 

M/- 

M/- 

/tut 

w 

certiEicaLe 

u/- 

u/- 

/n 
-/u 

new— creaent i a is 

M 

s  imple 

U/- 

r>  / 
U/- 

-/u 

Y 
A 

strong 

M/- 

M/- 

— /rl 

mr 

bind— token 

M/- 

M/- 

-/M 

certificate 

0/- 

0/- 

-/o 

extens  ions 

message— token 

M/- 

M/- 

/TUT 
— / M 

s  i  gned— data 

message— s ecu r i ty— label 

M/- 

-/M 

See  Note  1 

secur  i  ty— pol i  cy— i  dent  i  f  i  er 

/M 

rl 

encrypted-data 

message— secur  i  ty— label 

O/- 

O/- 

-/U 

content- integrity-check 

M/- 

M/- 

-/M 

M 

message-security-label 

M/- 

M/- 

-/M 

See  Note  1 

security-policy-identifier 

M/- 

M/- 

-/M 

M 

MessageDeli veryEnvelope 

extensions 

message-security-label 

-/M 

-/M 

M/- 

See  Note  1 

s  ecur  i  ty-pol i  cy- i  dent  i  f  i  er 

-/M 

-/M 

M/- 

M 

message-token 

-/M 

-/M 

M/- 

signed-data 

message-security-label 

-/o 

-/o 

0/- 

See  Note  1 

encrypted-data 

message-security-label 

-/o 

-/o 

0/- 

See  Note  1 
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Table  39  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  SI 

(concluded) 


MTS  Access  Protocol  (P3)  for 

Security  Class  SI 

Part     3  of  3 

Static  Support 

by: 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Protocol  Element 

Dyn 

Comments/References 

ReportDeliveryEnvelope 
extensions 
message-security-label 

-/M 

-/M 

M/- 

M 

See  Note  1 

bind-token 
asymmetric-token 
signature-algorithm-identifier 
name 
time 

signed-data 

encryption-algorithm- 
identifier 

encrypted-data 
message-security-label 
content-integrity-key 

-/M 
-/M 
-/M 
-/M 

-/M 
-/M 
-/M 
-/M 

-/M 
-/M 
-/M 
-/M 

-/M 
-/M 
-/M 
-/M 

M/- 
M/- 
M/- 
M/- 

M/- 
M/- 
M/- 
M/- 

M 
M 
M 
M 

Notes 

1    The  message-security-label  may  appear  in  any  or  all  of  the  indicated 
locations  in  the  envelope.  However,  the  security  labelling  context 
services  apply  only  to  the  label  in  the  "extensions"  field.  Labels  in  th 
message  token  have  only  end-to-end  (UA-to-UA)  significance. 
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Table  40  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  S2 


MTS  Access  Protocol  (P3)  for  Security  Class  S2 

Part    1  of  2 

Static  Support  byi 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Dvn 

Comments/References 

Protocol  Element 

Mes  s  ageSubmi  s  s  i  on 

RESULT 

extensions 

or  i  g  i  na t  i  ng— MTA— ce  rtificate 

-/M 

-/o 

M/- 

certificate 

-/- 

-/o 

-/- 

cert i f icat ion— path 

-/_ 

-/o 

-/- 

proof-of-submission 

-/M 

-/o 

M/- 

Mes sageDeli very 

RESULT 

recipient— cert  i  f i  cate 

M/- 

M/- 

-/o 

certi  f icate 

M/- 

M/- 

-/M 

cert i f icat ion— path 

M/- 

M/- 

-/M 

MessageSubmissionEnvelope 

extens  ions 

or  i  a  i  nator- cer t  i  f  i  cate 

M/- 

0/- 

-/M 

certificate 

-/- 

-/o 

-/- 

cert i f icat ion— oath 

/ 

-/o 

-/- 

message— or  ig in— 

authent  icat  ion— check 

M/- 

0/- 

-/M 

M 

algor  i  thm— i  dent  i  f  ier 

M/- 

M/- 

-/M 

content 

M/- 

M/- 

-/M 

content-ident  i  f ier 

M/- 

M/- 

-/M 

message-security-label 

M/- 

M/- 

-/M 

proof -of -submi  ss  ion-request 

M/- 

0/- 

— /M 

ProbeSubmi ss ionEnvelope 

extensions 

originator-certificate 

M/- 

0/- 

-/M 

certi  f icate 

-/- 

-/o 

-/- 

certification-path 

-/- 

-/o 

-/- 

probe-origin-authentication- 

check 

M/- 

0/- 

-/M 

M 

algorithm-identifier 

M/- 

M/- 

-/M 

content-identifier 

M/- 

M/- 

-/M 

message-security-label 

M/- 

M/- 

-/M 
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Part  8:  Message  Handling  Systems  December  1991  (Stable) 


Table  40  -  Conformance  classification  of  the  P3  protocol  elements  for  security  class  S2 

(concluded) 


MTS  Access  Protocol  (P3)  for  Security  Class  S2 

Part     2  of  2 

Static  Support  by: 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Dyn 

Comments/References 

Protocol  Element 

Me  s  s  ageDe liver  y En ve 1 ope 

extensions 

originator-certificate 

-/M 

-/M 

M/- 

certificate 

-/M 

-/M 

M/- 

cer t  i  f  i cat  ion-path 

-/M 

-/M 

M/- 

message-origin- 

authent  i  cat  i  on-check 

-/M 

-/M 

M/- 

M 

algorithm-identifier 

-/M 

-/M 

M/- 

content 

-/M 

-/M 

M/- 

content-identifier 

-/M 

-/M 

M/- 

message-security-label 

-/M 

-/M 

M/- 

ReportDeliveryEnvelope 

extensions 

reporting-MTA-certif icate 

-/M 

-/o 

M/- 

certificate 

-/- 

-/o 

-/- 

certification-path 

-/- 

-/o 

-/- 

report-origin-authentication- 

check 

-/M 

-/o 

M/- 

M 

PerRecipientReportDeli very- 

Fields 

extensions 

recipient-certificate 

-/M 

-/M 

0/- 

certificate 

-/M 

-/M 

M/- 

certification-path 

-/M 

-/M 

M/- 

Certificate 

version 

-/M 

-/M 

M/- 

ser ialNumber 

-/M 

-/M 

M/- 

signature 

-/M 

-/M 

M/- 

algorithm 

-/M 

-/M 

M/- 

parameters 

-/o 

-/o 

0/- 

issuer 

-/M 

-/M 

M/- 

validity 

-/M 

-/M 

M/- 

notBefore 

-/M 

-/M 

M/- 

notAf ter 

-/M 

-/M 

M/- 

subject 

-/M 

-/M 

M/- 

sub jectPublicKey Info 

-/M 

-/M 

M/- 

algorithm 

-/M 

-/M 

M/- 

sub jectPublicKey 

-/M 

-/M 

M/- 
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December  1991  (Stable) 


Table  41  presents  the  classification  delta  to  classification  tables  38,  39,  and  40,  for  the  addition  of  mandatory 
content  confidentiality  in  the  static  conformance  classification. 

NOTE  -  There  are  no  dynamic  conformance  classification  required  by  the  addition  of  content  confidentiality. 


Table  41  -  Conformance  classification  of  the  P3  protocol  elements  for  security  classes  SOa,  Sla,  or 

S2a 


MTS  Access  Protocol  (P3)  for  Security  Classes  SOa,  Sla,  S2a    Part    1  of  1 

Static  Support  by: 

UA 
0/R 

MS 
0/R 

MTA 
0/R 

Dyn 

Comments/References 

Protocol  Element 

MessageSubmissi  onEn ve 1 ope 
extensions 
content-conf  i  dent  i  al i  ty- 
algorithm- identifier 

asymmetric-token  , 
signed-data 
content-confidentiality- 
algorithm-identifier 
encrypted-data 
content-confidentiality- 
key 

MessageDeliveryEnvelope  ; 
extensions  ' 
message- token 
asymmetric-token 
signed-data 
content-confidentiality- 
algorithm-identifier 
encrypted-data 
content-confidentiality- 
key 

content-confidentiality- 
algorithm-identifier 

M/- 

M/- 
M/- 

M/- 

-/M 
-/M 
-/M 

-/M 
-/M 

0/- 

-/- 
-/- 

-/- 

-/M 
-/M 
-/M 

-/M 
-/M 

-/o 

-/- 

-/- 

-/- 

0/- 
-/- 
-/- 

-/- 
0/- 

See  Note  1 
See  Note  1 

See  Note  1 
See  Note  1 

Notes 

1     Implementors  shall  generate  no  more  than  one  instance  of  these 
identically  named  protocol  elements  in  a  single  message. 

I 
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December  1991  (Stable) 


A.7     Classification  of  the  P7  Protocol  Elements  for  Security  Classes 

The  protocol  element  classifications  in  table  42  should  be  viewed  as  a  delta  to  the  lower  security  class  or, 
if  there  is  no  lower  security  class,  to  the  kernel  as  classified  in  table  35.  Thus,  table  42  shows  the  additional 
support  required  in  P7  to  conform  to  security  class  S1. 

NOTES 

1  There  are  no  additional  classifications  for  security  classes  SO  and  S2. 

2  The  addition  of  mandatory  content  confidentiality  does  not  affect  the  P7  protocol. 
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Part  8:  Message  Handling  Systems  December  1991  (Stable) 


Table  42  -  Conformance  classification  of  the  P7  protocol  elements  for  security  class  SI 


MS  Access  Protocol  (P7)  for  Security  Class  SI 

Part    1  of  1 

Static  Support  by: 

UA 
0/R 

MS 
0/R 

Dyn 

Comments/References 

Protocol  Element 

MSBind 

ARGUMENT 

simple 

0/- 

-/o 

X 

strong 

M/- 

-/M 

M 

bind-token 

M/- 

-/M 

M 

certificate 

0/- 

-/o 

secur  i  ty-cont ext 

M/- 

-/M 

M 

RESULT 

responder-credentials 

M 

simple 

-/o 

0/- 

X 

strong 

-/M 

M/- 

M 

bind-token 

-/M 

M/- 

M 

certi  f icate 

-/o 

0/- 

Register-MS 

ARGUMENT 

Register-MSArgument 

M 

old-credentials 

M/- 

-/M 

M 

simple 

0/- 

-/o 

M 

strong 

M/- 

-/M 

X 

bind-token 

M/- 

-/M 

M 

certificate 

0/- 

-/o 

M/- 

-/M 

M 

simple 

0/- 

-/o 

X 

strong 

M/- 

-/M 

M 

bind-token 

M/- 

-/M 

M 

certi  f icate 

0/- 

-/o 

user-security-labels 

M/- 

-/M 

M 

message-security-label 

security-policy-identifier 

M/- 

-/M 

M 

security-classification 

M/- 

-/M 

privacy 

0/- 

-/o 

security-categories 

M/- 

-/M 

A.8      Message  Store  General  Attribute  Support 

Table  43  specifies  tlie  classification  of  the  Message  Store  General  Attributes. 
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Table  43  -  Classification  of  the  message  store  general  attributes 


Message  Store  General  Attribute  Support 

Part  1  of  2 

Support  by: 

Bas 

Enchanced 

UA 

MS 

MS 

Attribute 

S 

R 

0 

0 

Comments/References 

chi Id-sequence-numbers 

M 

M 

M 

M 

content 

M 

M 

M 

M 

content-confidentiality- 

algorithm-identifier 

0 

0 

0 

0 

content-correlator 

0 

0 

0 

M 

content-identifier 

0 

0 

0 

M 

content-integr  i  ty-check 

0 

0 

0 

0 

content-length 

0 

0 

M 

M 

content-returned 

0 

0 

0 

M 

content-type 

M 

M 

M 

M 

conver s  ion-wi  th-loss-prohibi  ted 

0 

0 

0 

M 

converted-eits 

0 

0 

0 

M 

creation-time 

M 

M 

M 

M 

delivered-eits 

0 

0 

M 

M 

delivery-flags 

0 

0 

0 

M 

dl-expans  ion-hi  story 

0 

0 

0 

M 

entry-status 

M 

M 

M 

M 

entry-type 

M 

M 

M 

M 

intended-recipient-neune 

0 

0 

0 

M 

message-delivery-envelope 

M 

M 

M 

M 

message-delivery-identifier 

0 

0 

0 

M 

message-delivery-time 

0 

0 

0 

M 

message-origin-authentication- 

check 

0 

0 

0 

0 

message-security-label 

0 

0 

0 

0 

message-submission- time 

0 

0 

0 

M 

message-token 

0 

0 

0 

0 

original-eits 

0 

0 

0 

M 

originator-certificate 

0 

u 

r\ 

u 

0 

originator-name 

0 

0 

0 

M 

other-recipient-names 

0 

0 

0 

M 

parent-sequence-number 

M 

M 

M 

M 

per-r eci pi ent-report-deli very- 

fields 

M 

M 

M 

M 

priority 

0 

0 

M 

M 

proof-of-deli very-request 

0 

0 

0 

0 

redirection-history 

0 

0 

0 

M 

report-delivery-envelope 

M 

M 

M 

M 

report ing-dl-name 

0 

0 

0 

M 

reporting-mta-certif icate 

0 

0 

0 

0 
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Table  43  -  Classification  of  the  message  store  general  attributes  (concluded) 


Message  Store  General  Attribute 

Support 

Part  2  of  2 

Support 

by: 

UA 
R 

Bas 
MS 
0 

Enhanced 

Attribute 

S 

no 
0 

Comments/References 

report-origin-authentication- 
check 

security-classification 
sequence-number 
subject-submission-identifier 
this-recipient-name 

0 
0 
M 
M 
0 

0 
0 
M 
M 
0 

0 
0 
M 
M 
0 

0 
0 
M 
M 
M 

Note  -    Enhanced  MS  support  for  optional  Functional  Groups  is  for 
further  study.  Attributes  which  are  relevant  to  these  areas  are 
currently  specified  as  Unsupported. 

4  . 
Vi 

it  ■ 
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December  1991  (Stable) 


A.9      Classification  of  the  MS  General  Attributes  for  Security  Classes 

The  classification  of  the  attributes  in  table  44  is  a  delta  to  the  Enhanced  MS  column  of  the  MS  General 
Attributes  in  table  43.  Table  44  indicates  the  additional  attributes  that  must  be  supported  in  the  MS  for  each 
of  the  security  classes.  There  is  no  support  required  for  security  attributes  in  the  basic  MS. 


Table  44  -  MS  security  attribute  support 


Security  Class 

Attribute 

SO 

SOa 

SI 

Sla 

S2 

S2a 

cont ent-conf  i  dent  ial i  ty-algor  i  thm- 

identif ier 

0 

M 

0 

M 

0 

M 

content- integrity-check 

M 

M 

M 

M 

M 

M 

message-security-label 

0 

0 

M 

M 

M 

M 

message-origin-authentication-check 

M 

M 

M 

M 

M 

M 

message- token 

M 

M 

M 

M 

M 

M 

origination-certificate 

0 

0 

0 

0 

M 

M 

proof-of-delivery 

M 

M 

M 

M 

M 

M 

reporting-mta-certif icate 

0 

0 

0 

0 

M 

M 

report-origin-authentication-check 

0 

0 

0 

0 

M 

M 

security-classification 

0 

0 

M 

M 

M 

M 
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December  1991  (Stable) 


A.10    Message  Store  IPM  Attribute  Support 

Table  45  specifies  tlie  classification  of  the  Message  Store  IPM  attributes.  This  clause  is  to  be  read  in 
accordance  with  Annex  C  of  X.420  (1988).  For  support  of  MS  General  Attributes,  see  table  43,  enhanced 
MS  column. 


Table  45  -  Classification  of  the  message  store  IPM  attributes 


Message  Store  IPM  Attribute  Support 

Part  1  of  2 

Support  by: 

TPM 

UA 
p 

TPM 

X  XT  11 

MS 

Attr  ibute 

s 

1  TiTTl  — OTl  "f"  T"  \7— VTiO 

0 

M 

ipm-synopsis 

0 

M 
1 1 

Ha;^  Hinn   A'h'hr'i  Hii  1"  • 

0 

0 

M 

M 
11 

0 

n 

M 
1 1 

poriv— rpp  i  "Di  pnt"  s 

0 

o 

M 

^  A    X  L  y     1^  X 111^ 

0 

0 

M 

Y\  p^  H  1 

M 

M 

M 

importance 

0 

o 

M 
11 

incomplete-copy 

0 

o 

V-/ 

V-/ 

languages 

0 

0 

M 

nrn-requestors 

0 

0 

M 

obsoleted-ipms 

0 

0 

M 

originator 

0 

0 

M 

primary-recipients 

0 

0 

M 

related-ipms 

0 

0 

M 

replied-to-ipm 

0 

0 

M 

reply-recipients 

0 

0 

M 

reply-requestors 

0 

0 

M 

reply-t  ime 

0 

0 

M 

,  rn-requestors 

0 

0 

M 

sensitivity 

0 

0 

M 

subject 

0 

0 

M 

this-ipm 

M 

M 

M 

Body  Attributes: 

bilaterally-def ined-body- 

parts 

0 

0 

0 

body 

M 

M 

M 

encrypt ed-body-parts 

0 

0 

0 

encrypted-data 

0 

0 

0 

encrypt ed-parameters 

0 

0 

0 

extended-body-part-types 

0 

0 

0 
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Table  45  -  Classification  of  the  message  store  IPM  attributes  (concluded) 


Message  Store  IPM  Attribute  Support 

Part  2  of  2 

Support  by: 

IPM 
UA 
R 

IPM 
MS 
0 

Attribute 

s 

Comments/References 

g3-f acsimile-body-parts 

0 

0 

0 

g3-f acsimile-data 

0 

0 

0 

g3-f  acsiini  le-parameters 

0 

0 

0 

g4—c las si— body— parts 

0 

0 

0 

ia5- text-body-parts 

0 

0 

M 

ia5- text-data 

0 

0 

0 

ia5— text— parameters 

0 

0 

0 

message-body-parts 

0 

0 

M 

message-data 

0 

0 

0 

message-parameters 

0 

0 

0 

mixed-mode-body-parts 

0 

0 

0 

nat  i  ona 1 ly-de  f  i  ned-body-par  t  s 

0 

0 

0 

teletex-body-parts 

0 

0 

0 

teletex-data 

0 

0 

0 

t el et ex-parameters 

0 

0 

0 

videotex-body-parts 

0 

0 

0 

videotex-data 

0 

0 

0 

videotex-parameters 

0 

0 

0 

vo  i  c  e-body-pa  r  t  s 

0 

0 

0 

voice-data 

0 

0 

0 

voice-parameters 

0 

0 

0 

oda-1984-body-parts 



0 

0 

iso6937-body-parts 

_ 

0 

0 

bi later ally-defined-body- 

parts 



0 

0 

usa-pri vately-def ined-body- 

par  ts 

0 

0 

Notification  Attributes: 

acknowl edgment -mode 

0 

0 

M 

auto-forward-coiament 

0 

0 

M 

conversion-eits 

0 

0 

M 

discard-reason 

0 

0 

M 

ipm-prefer red-recipient 

0 

0 

M 

ipn-originator 

0 

0 

M 

non-receipt-reason 

0 

0 

M 

receipt-time 

0 

0 

M 

returned-ipm 

0 

0 

0 

sub ject-ipm 

M 

M 

M 

suppl-receipt-info 

0 

0 

0 
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A.1 1     EDI  Messaging  Service  Protocol  (Pedi) 

A.12    Message  Store  EDIMS  Attribute  Support 

A.13    Classification  of  the  P3  Protocol  Elements  for  Physical  Delivery 

See  Working  Document. 
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Annex  B  (normative) 
Object  Identifiers 

B.I      X.400  SIG  Object  Identifiers 

The  X.400  SIG  object  identifiers  all  allocated  under  the  mhsig  node  in  the  OIW  object  identifier  subtree,  as 
defined  in  part  6  of  the  Stable  Implementors  Agreements  document.  This  definition  is  duplicated  in  figure 
15. 


id-mhsig    OBJECT  IDENTIFIER  ::= 

{  iso  (1)     identif ied-organization  (3)     oiw  (14)     mhsig  (6)  } 


Figure  15  -  Definition  of  the  mhsig  object  identifier 

For  additional  information  on  this  subject,  see  the  Working  Document. 


B.2      Content  Types 

See  Working  Document. 


B.3      Body  Part  Types 

See  Working  Document. 


B.4     Security  Classes 

The  ASN.1  expressed  in  figure  18  defines  the  security  Object  Identifiers  specified  by  these  Implementation 
Agreements.  These  are  the  same  as  defined  in  the  EWOS/ETSI  A/3311  profile. 
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id-mhs-security  OBJECT  IDENTIFIER  ::=  {  iso  (1) 

identif ied-organization  (3)  ewos  (16)  eg  (2)  mhs  (4)  security  (4)  } 


id-policy- id 
id-category-id 


OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 


—  Security  Policy  Object  Identifiers  — 


secur ity-class-0 
secur ity-class-Oa 
secur ity-class-1 
security-class-la 
secur ity-class-2 
secur ity-class-2a 


OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 
OBJECT 


IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 
IDENTIFIER 


—  Security  Category  Object  Identifiers  — 


private-id 
confidence-id 

commercial-in-conf idence-id 
management -in-confidence- id 
per sonal-in-conf idence-id 


OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 
OBJECT  IDENTIFIER 


;=  f  id-mhs-security  1  } 
;=  {  id-mhs-security  2  } 


if 


{  id-policy-id  0  } 

{  id-policy-id  0  1} 

{  id-policy- id  1  } 

id-policy- id  11} 

id-policy-id  2  } 

{  id-policy-id  2  1} 


{  id-category-id  0  } 

{  id-category-id  1  } 

id-category-id  2  } 

id-category-id  3  } 

{  id-category-id  4  } 


Figure  18  -  Security  object  identifiers 
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Annex  C  (informative) 

Interpretation  of  Elements  of  Service 

The  objective  of  this  clause  is  to  provide  clarification,  where  required,  on  the  functionality  of  Elements  of 
Service  where  the  MHS  standards  are  unclear  or  ambiguous.  It  is  not  the  intent  of  this  clause  to  define  how 
information  should  be  made  available  or  presented  to  an  MHS  user,  nor  is  it  intended  to  define  how 
individual  vendors  should  design  their  products. 

The  following  MHS  Elements  of  Service  require  further  text  to  be  added  to  their  definitions  to  represent  the 
proposed  implementation  of  these  Elements  of  Service  for  conformance  to  this  Agreement.  Elements  of 
Service  which  are  not  referenced  in  this  clause  are  as  defined  in  the  MHS  base  standards. 

Reply  Request  Indication:  The  reply-recipients  and  the  reply-time  may  be  specified  without  any  explicit  reply 
being  requested.  This  may  be  interpreted  by  the  recipient  as  an  implicit  reply  request. 

NOTE  -  For  an  auto-forwarded  message  an  explicit  or  implicit  reply  request  may  not  be  meaningful. 

Forwarded  IP-message  Indication:  The  following  use  of  the  original  encoded  information  type  in  the  context 
of  forwarded  messages  is  clarified: 

a)  The  encoded  information  types  of  the  message  being  forwarded  should  be  reflected  in  the  new 
original  encoded  information  types  being  generated. 

b)  If  forwarding  a  privately  defined  body  part  (see  figure  10),  the  originator  of  the  forwarding 
message  shall  set  the  original  encoded  information  types  in  the  PI  envelope  to  Undefined  for  that 
body  part. 
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Annex  D  (informative) 
Recommended  Practices 

This  clause  provides  guidelines  on  areas  not  addressed  by  the  base  standards.  These  guidelines  have  been 
produced  in  order  to  promote  awareness  of  interim  solution  to  problems  as  agree  by  members  of  the  OIW 
X.400  SIG.  However  implementors  of  these  recommended  practices  should  note  that  it  is  not  necessary  to 
follow  the  recommended  practices  when  claiming  conformance  to  these  agreements. 

Implementors  should  also  note  that  future  standardization  by  CCITT  and  ISO/IEC  on  area  covered  by  this 
clause  may  result  in  different  solutions  to  those  proposed  in  this  clause. 


D.I      Printable  String 

There  are  existing  mail  systems  that  include  a  small  set  of  non-Printable  String  characters  in  their  identifiers. 
For  these  systems  to  communicate  with  MHS  systems,  either  for  pass-through  service  or  delivery  to  MHS 
users,  gateways  will  be  employed  to  encode  these  special  characters  into  a  sequence  of  Printable  String 
characters.  This  conversion  should  be  performed  by  the  gateway  according  to  a  common  scheme  and 
before  insertion  in  Domain  Defined  Attributes,  which  are  intended  to  carry  electronic  mail  identifiers.  MHS 
UAs  may  also  perform  such  conversions. 

It  is  recommended  that  the  following  symmetrical  encoding  and  decoding  algorithm  for  non-Printable  String 
characters  be  employed.  The  encoding  algorithm  maps  an  ASCII  representation  to  a  PrintableString 
representation.  Any  non-printable  string  characters  not  specified  in  table  49  are  covered  by  the  category 
"other." 


Table  49  -  Printable  String  to  ASCII  Mapping 


ASCII  Character 

Printable  String  Character 

%  (percent) 

(P) 

§  (at  sign) 

(a) 

!  (exclamation) 

(b) 

"  (quote  mark) 

(q) 

_  (underline) 

(u) 

(   ( left  paren. ) 

(1) 

)   (right  paren. ) 

(r) 

other 

(3DIGIT) 

where  3DIGIT  has  the  range  000  to  377  and  is  interpreted  as  the  octal  encoding  of  an  ASCII  character. 

To  encode  an  ASCII  representation  to  a  PrintableString,  table  48  and  the  algorithm  in  figure  19  should  be 
used. 
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IF  current  character  is  in  the  encoding  set  THEN 

encode  the  character  according  to  table  48 
ELSE 

write  the  current  character; 
continue  reading; 


Figure  19  -  ASCII  to  printableString  algorithm 

To  decode  a  PrintableString  representation  to  an  ASCII  representation,  table  48  and  the  algorithm  in  figure 
20  should  be  used. 


IF  current  character  is  not  "("  THEN 

write  character 
ELSE 

{ 

look  ahead  appropriate  characters; 

IF  composite  characters  are  in  table  48  THEN 

decode  per  table  48 
ELSE 

write  current  character; 
continue  reading; 


Figure  20  -  PrintableString  to  ASCII  algorithm 


D.2      Rendition  of  lASText 

The  characters  that  nriay  be  used  in  an  lASString  are  the  graphic  characters  (including  Space),  control 
characters  and  Delete  of  the  IA5  character  repertoire  ISO  646. 

The  graphic  characters  that  may  be  used  with  a  guaranteed  rendition  are  those  related  with  positions  2/0 
to  2/2,  2/5  to  3/15,  4/1  to  5/10,  5/15  and  6/1  to  7/10  in  the  basic  7-bit  code  table. 

The  other  graphic  characters  may  be  used  but  have  no  guaranteed  rendition. 

The  control  characters  that  may  be  used  but  have  no  guaranteed  effect  are  a  subset  consisting  of  the  format 
effectors  0/10  (LF),  0/12  (FF)  and  0/13  (CR)  provided  they  are  used  in  one  of  the  following  combinations 
as  defined  in  table  50. 


Table  50  -  Interpretation  of  format  effector  combinations 


Combination 

Interpretation 

CR  LF 
CR  FF 
LF  . .  LF 

to  start  a  new  line 
to  start  a  new  page  (and  line) 
to  show  empty  lines  (always  after  one  of  the 
preceding  combinations). 

The  other  control  characters  or  the  above  control  characters  in  different  combinations  may  be  used  but  have 
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no  guaranteed  effect. 

The  character  Delete  may  occur  but  has  no  guaranteed  effect.  The  lASString  in  a  P2  lASText  BodyPart 
represents  a  series  of  lines  which  may  be  divided  into  pages.  Each  line  should  contain  from  0  to  80  graphic 
characters  for  guaranteed  rendition.  Longer  lines  may  be  arbitrarily  broken  for  rendition. 

NOTE  -  X.408  states  that  for  conversion  from  lASText  to  Teletex,  the  maximum  line  length  is  77  characters. 


This  clause  presents  a  recommended  method  for  intenA/orking  a  P(edi)  UA  with  a  UA  following  the 
Recommended  Practices  in  part  7  of  the  OIW  Stable  Implementation  Agreements  for  support  of  EDI  data 
transfer  in  an  MHS  (1984)  environment.  The  Part  7  Recommended  Practice  is  referred  to  as  "PO." 

This  Recommended  Practice  does  not  say  anything  about  where  this  conversion  occurs.  It  could  be 
performed  by  the  PO  UA,  the  P(edi)  UA,  or  a  gateway.  It  only  recommends  the  conversion  rules  to  be 
followed. 


D.3.2       PO  to  P(edi)  Conversion 

If  an  EDI  message  comes  in  from  a  1984  MTA  with  a  content  type  of  PO,  the  EDIM  Heading  fields  of  the  new 
P(edi)  message  can  be  formed  using  the  following  rules: 

EDIMIdentifier:  Originator  ORName  concatenated  with  the  UTCTime  at  which  the  conversion  from  PO  to 
P(edi)  was  performed. 

Originator:  Originator  ORName. 

Recipients:  Recipients  from  the  PI  envelope.  No  EDI  Notification  Requests  are  specified. 

EDIBodyPartType:  Value  for  ANSI  X12/EBCDIC  if  the  Encoded  Information  Types  (EIT)  field  of  the  P1 
envelope  has  the  value  "undefined,"  value  for  ANSI  X12/IS0646  if  the  EIT  has  the  value  "IA5  String,"  or  any 
other  valid  value  if  the  entity  performing  the  conversion  can  determine  the  EDI  syntax  contained  in  the 
content  and  which  character  encoding  is  used  for  the  EDI  syntax. 

Other  heading  fields  will  only  be  set  if  the  entity  performing  the  conversion  is  capable  of  parsing  the  EDI 
Interchange  and  discovering  the  correct  values  of  EDI  HEading  fields. 

Since  no  notification  requests  will  be  used,  the  EDI  UA  will  never  create  an  EDIN  when  it  receives  an  EDIM 
converted  from  a  PO  type  EDI  message. 


D.3 


EDI  Use  of  MHS 


D.3.1 


Introduction  and  Scope 
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D.3.3       P(edi)  to  PO  Conversion 

Going  the  other  direction  and  trying  to  downgrade  a  P(edi)  EDIM  to  be  carried  by  an  MTA  using  PO  to  carry 
EDI  messages,  the  following  rules  apply: 

The  first  body  part  of  the  EDIM  will  be  copied  as  the  content.  All  other  body  parts  of  the  EDIM  will  be 
discarded. 

P1  envelope  fields  will  be  set  as  follows: 
Content  Type:  Undefined  (0). 
Originator:  Originator  ORName. 

Recipients:  Recipients  are  set  from  the  EDIM  Heading.  An  NN  EDIN  with  NN  Reason  Code  set  to  the  value 
"unspecified"  is  created  for  each  Recipient  for  whom  a  Notification  Request  was  specified.  The  EDIN 
Originator  is  set  to  the  Recipient  ORName.  If  the  entity  performing  the  conversion  accepts  responsibility 
for  the  EDIM,  it  will  generate  a  PN  instead  of  an  NN,  if  notification  is  requested. 

Encoded  Information  Types  (EITs):  Set  to  "undefined"  if  the  EDI  body  part  type  is  encoded  with  the  EBCDIC 
character  set,  set  to  "IA5  String"  if  the  EDI  body  part  is  encoded  in  ISO  646  (ASCII),  and  not  present 
otherwise. 

D.4     Textual  Representation  of  0/R  Names 


D.5      ODA  Transfer 


To  ease  interworking  with  1984  implementations  when  transferring  Office  Document  Architecture  (ODA) 
documents,  the  following  are  recommended  for  1988  implementations: 

a)  Origination  UA  implementing  1988  Implementation  Agreements.  The  1988  will  generate  the  ODA 
according  to  CCITT  Recommendation  T.41 1  Annex  E  for  the  destination  UA(s)  implementing  1988 
Implementation  Agreements.  If  the  destination  UA  supports  1984  Implementation  Agreements,  the 
approach  as  described  in  section  7.12.8  is  recommended. 

b)  Recipient  UA  implementing  1988  Implementation  Agreements.  The  recipient  system  will  be  able 
to  handle  the  ODA  bodypart  in  P2  (1984)  as  defined  in  part  7,  B.8.1  for  interworking  with  1984 
implementation,  and  will  also  be  able  to  handle  the  ODA  bodypart  as  defined  in  the  appropriate 
base  standards. 

c)  MTA  downgrading  rules.  When  transferring  an  P22  with  ODA  body  part  in  P22  as  described  in 
T.411  to  an  1984  MTA,  the  EITs  identified  by  ODA  Object  Identifiers  are  mapped  to  bits  0  and  10 
of  the  built-in  EITs. 

If  the  UA  does  not  register  to  support  P22  or  ODA  bodypart,  a  Non-Delivery-Report  will  be  generated  as 
required. 
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D.6     Use  of  Externally  Defined  Body  Part 

The  Externally  Defined  Bcxiy  Part  allows  the  identification  of  various  types  of  information  exchanged  between 
UAs.  This  capability  allows  a  UA  on  reception  to  recognize  the  appropriate  application  to  process  the 
infornnation,  e.g.,  to  automatically  invoke  the  application.  It  also  allows  the  MTS  to  possibly  convert  from  one 
type  to  another  (e.g.,  to  convert  a  word-processing  document  to  ODA).  For  example,  a  spreadsheet 
application  on  a  personal  computer  from  vendor  A  by  operating  system  X  can  send  via  X.400  to  the  UA  on 
workstation  from  vendor  B  using  operating  system  Y,  and  the  latter  will  be  able  to  recognize  and  possible 
invoke  the  appropriate  spreadsheet  application  to  process  the  data. 


The  Externally  Defined  Body  Part  definition  is  reproduced  in  figure  22. 


ExternallyDef inedBodyPart 
parameters 
data 

ExternallyDef inedParameters 
ExternallyDef inedDat a 

EXTERNAL 

direct-reference 
indirect-reference 
data-value-descr  iptor 
encoding 

single-ASNl-type 

octet-aligned 

arbitrary 


SEQUENCE  { 

[0]  ExternallyDef inedParameters  OPTIONAL, 
ExternallyDef inedData  ) 

EXTERNAL 
EXTERNAL 

[UNIVERSAL  8]     IMPLICIT  SEQUENCE  { 
OBJECT  IDENTIFIER  OPTIONAL, 
INTEGER  OPTIONAL, 
ObjectDescriptor  OPTIONAL, 
CHOICE  { 
tO]  ANY, 

[1]     IMPLICIT  OCTET  STRING. 
[2]     IMPLICIT  BIT  STRING     }  } 


Note  -    In  the  case  of  transfer  of  EXTERNAL  in  P2  BodyPart,  the 
direct-reference  component  is  mandatory  and  the  indirect-reference  and 
data-value-descriptor  components  must  be  absent. 


Figure  22  -  Externally  defined  body  part  definition 
The  following  recommends  how  to  use  the  components  of  this  BodyPart: 


a)  Use  of  Parameters  component:  In  simple  cases,  to  ease  the  integration  of  applications  to  X.400 
systems,  the  Parameters  component  need  not  be  used. 

b)  Use  of  Data  component:  For  each  different  format  of  data,  different  Object  Identifiers  for  the  Data 
component  are  recommended.  If  an  application  chooses  to  use  ASN.1  to  format  the  data  to  achieve 
a  single  representation  across  platforms,  the  single-ASN1-type  encoding  choice  should  be  used. 
Otherwise: 

1)  The  octet-  (I.e.,  byte)  aligned  choice  is  used  if  the  data  format  is  octet-aligned;  or, 

2)  The  arbitrary  choice  is  used  if  the  data  is  bit-aligned. 

c)  Assignment  of  Object  Identifiers:  Object  Identifiers  need  to  be  assigned  for  the  EXTERNALS,  and 
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these  identifiers  for  the  Parameters  and  Data  connponents  should  be  different.  The  Object  Identifier 
for  an  EXTERNAL  also  indicates  the  syntax  of  the  data  encoding,  i.e.,  whether  single-ASN1-type  or 
octet-aligned  or  bit-aligned  is  being  used. 

NOTE  -  Whether  the  Object  Identifier  needs  to  be  present  in  this  case  is  for  further  study. 
There  are  many  ways  to  obtain  object  Identifiers.  One  such  way  is  described  as  follows: 

a)  The  application  provider  obtains  a  unique  Numeric  Name  form  for  their  organization  from  ANSI, 
as  described  in  ANSI  ISSB  840  and  ISSB  843,  and  appends  this  number  form  to  {iso  (1)  member- 
body  (2)  US  (840)}  to  form  an  object  identifier  denoting  their  organization; 

b)  The  application  provider  (organization)  allocates  a  series  of  numbers  to  identify  the  application 
data  format;  these  numbers  are  appended  to  the  object  identifier  constructed  in  step  (i)  to  form  an 
object  identifier  that  is  globally  unique.  It  is  recommended  that  the  application  provider 
(organization)  use  a  hierarchical  structure  for  identifying  their  data  types  to  ease  the  administration 
of  the  identifiers. 

For  example,  company  PCSoftware  Inc.  obtains  the  organization  number  "999"  from  ANSI.  The  PCSoftware 
Spreadsheet  file  for  MS-DOS  might  be  assigned  the  following  object  identifier. 

NOTE  -  ASN.1  notation  is  used.  The  numbers  in  parentheses  form  the  identifier,  the  associated  words 
describe  the  number. 

{  iso  (1)  member-body  (2)  US  (840)  PCSoftware  Inc.  (999)  MS-DOS-Application  (1)  Spreadsheet 
(3)  Data  (1)  } 

Since  the  Spreadsheet  data  format  for  MS-DOS  does  not  follow  ASN.1  encoding  rules  and  is  octet-aligned, 
the  encoding  choice  for  the  Data  EXTERNAL  is  octet-aligned. 

It  is  also  recognized  that  not  all  objects  will  be  registered  as  indicated  above.  In  order  to  transfer 
unregistered  data.  It  is  recommended  that  they  be  transferred  in  the  BilaterallyDefinedBodyPart. 

It  is  recommended  that  a  1988  system  be  able  to  support  the  Undefined  Body  Part  (14),  if  it  also  supports 
Extended  Body  Parts.  This  is  in  order  to  facilitate  inter-working  with  1984  systems. 


D.7     Privacy  Enchanced  Mail  Body  Part 

See  Working  Document. 
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D.8     Selection  of  OR  Name  Attributes 

To  support  the  transition  to  addresses  with  Teletex  components,  It  is  recommended  that  a  printable  string 
alternative  address  be  established  for  each  address  containing  Teletex  strings. 
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Annex  E  (informative) 

Secure  Messaging  Guidelines 

E.I  Introduction 

The  purpose  of  the  security  functional  group  is  to  define  an  approach  to  the  provision  of  secure  messaging 
with  Message  Handling  systems  within  the  general  framework  of  these  Implementation  Agreements. 

E.2      Message  Handling  Vulnerabilities 

The  message  handling  vulnerabilities  (threats)  which  can  be  protected  using  security  measures  are  defined 
in  Annex  D  (Security  Threats)  to  Recommendation  X.402  (1988): 

a)  Masquerading; 

b)  Message  sequencing; 

c)  Modification  of  information; 

d)  Denial  of  service; 

e)  Repudiation; 

f)  Leakage  of  information. 

Other  specific  threats  exist  if  there  is  a  failure  to  maintain  information  separation,  which  includes: 

a)  Manipulation; 

b)  Misrouting. 

Some  of  these  threats  are  defined  in  ISO  standard  IS  7498,  OSI  Reference  Model,  Part  2:  Security 
Architecture.  The  ISO  standard  also  specifies  other  threats,  not  all  of  which  are  relevant  to  message  handling 
systems. 

Annex  D  to  CCITT  Recommendation  X.402  (1988)  also  indicates  which  MHS  security  services  may  provide 
protection  against  such  threats. 

Some  threats  to  message  handling  systems  cannot  be  easily  prevented,  merely  detected,  others  are  not 
appropriated  for  standardization. 
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E.3      General  Principles 


E.3.1       Security  Policy 

A  general  security  policy  can  be  defined  as  the  set  of  laws,  rules,  and  practices  that  regulate  how  an 
organization  manages,  protects,  and  distributes  sensitive  information.  Thus  a  security  policy  defines  an 
organization's  overall  approach  to  security  and  must  cover  all  security  aspects. 

Security  within  an  organization  is  not  only  the  concern  of  message  handling  service  and  must  be  viewed 
in  a  more  global  and  general  sense.  The  wider  aspects  of  a  security  policy  would  therefore  include 
personnel  security  (such  as  the  vesting  and  confidence  placed  in  staff),  end-user  access  control,  physical, 
procedural  and  documentation  security.  These  Implementation  Agreements  however  are  only  concerned  with 
Electronic  Information  Security  (EIS),  specifically  in  the  areas  of  communications  (COMSEC)  and  computer 
(COMPUSEC)  as  applicable  to  standardization  of  a  secure  message  handling  system  operating  in  a  store 
and  forward  environment. 


E.3.2       Security  Classes 

In  the  X.400  (1988)  Recommendations,  some  threats  are  countered  by  EIS  measures,  these  measures  are 
realized  by  providing  security  services  and  implemented  using  security  elements. 

These  Implementation  Agreements  groups  together  security  features  of  a  message  handling  system  defined 
by  the  base  standards  into  separate  classes.  A  security  class  can  be  viewed  as  a  tool  which  can  be  used 
to  implement  a  security  policy,  and  is  not  a  security  policy  in  its  own  right  but  a  component  of  a  security 
policy. 

These  Implementation  Agreements  includes  a  set  of  security  classes;  each  class  stipulates  a  set  of 
mandatory  and  optional  security  services.  The  security  classes  are  incremental  subsets  of  the  security 
features  in  the  MHS  Base  Specifications: 

Security  Class  SO  only  requires  support  of  end-to-end  security  services  between  UAs  (content 
integrity,  message  origin  authentication,  proof  of  delivery),  and  hence  can  be  used  to  provide  some 
protection  even  in  the  case  of  transit  through  an  intermediary  MTS  which  may  not  be  trusted. 

Security  Class  S1  additionally  requires  support  and  use  of  secure  access  management  within  the 
MTS  so  as  to  allow  the  enforcement  of  a  label-based  security  policy  and  enable  trusted  interworking 
between  security  domains. 

Security  Class  S2  additionally  requires  support  and  use  of  origin  authentication  checks  within  the 
MTS  to  verify  the  origin  of  messages,  probes,  and  reports,  thereby  making  it  possible  to  provide 
non-repudiation  within  the  MTS. 

Mandatory  security  services  within  a  security  class  can  be  selected  by  the  subscriber  or  user,  either  on  a 
per-message  basis,  or  for  an  agreed  contractual  period  of  time.  It  is  a  local  issue  to  determine  when  a 
mandatory  security  service  is  offered  for  user  selection  or  when  it  is  permanently  invoked.  Facilities  and 
mechanisms  to  support  the  mandatory  security  services  must  always  be  provided  within  the  security  class, 
which  specifies  the  services  as  "mandatory." 
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E.3.3       Dynamic  Behavior  Requirements 

The  use  of  some  security  services  is  always  required  for  certain  security  classes.  This  is  specified  in  these 
Implementation  Agreements  by  imposing  additional  dynamic  requirements,  to  those  specified  in  the  base 
standards,  ensuring  that  the  corresponding  protocol  elements  are  always  present. 

Similarly,  use  of  some  security  services  are  prohibited  for  certain  security  classes.  This  is  specified  in  these 
Implementation  Agreements  by  imposing  additional  dynamic  requirements  to  those  specified  in  the  base 
standards,  ensuring  that  the  protocol  elements  are  never  present. 


E.3.4       Encryption  Techniques 

The  secure  messaging  facilities  defined  in  the  base  standards  are  provided  using  three  basic  security 
techniques,  namely: 

a)  Symmetric  encryption; 

b)  Asymmetric  encryption; 

c)  Trusted  functionality  (i.e.,  COMPUSEC  measures). 

The  base  standards  permit  the  use  of  the  techniques  on  an  individual  basis  to  provided  security  services 
or  they  can  be  combined  in  support  of  a  security  policy.  These  Implementation  Agreements  combine  the 
techniques  in  order  to  provide  a  comprehensive  set  of  security  facilities,  which  are  intended  to  counter 
various  combinations  of  the  vulnerabilities  of  a  messaging  service.  In  some  cases  the  security  services 
defined  in  the  base  standards  can  only  be  implemented  using  one  of  the  techniques  above,  namely 
asymmetric  encryption.  However,  the  actual  technique  employed  shall  be  dependent  on  the  algorithms, 
which  shall  be  registered  by  a  security  authority  for  the  domain. 

It  is  the  intention  of  these  Implementation  Agreements  that  implementations  will  not  be  restricted  to 
asymmetric  techniques.  All  the  mandatory  security  services  can  be  implemented  using  trusted  functionality 
in  combination  with  symmetric,  asymmetric,  or  both  encryption  techniques. 

Although  the  base  standards  defines  the  syntax  of  an  asymmetric  token,  these  Implementation  Agreements 
tal<es  into  account  the  ISO/CCITT  MHS  Implementors'  Guide,  which  permits  the  use  of  both  asymmetric 
and  symmetric  techniques  for  both  the  signed  and  encrypted  data. 

The  actual  technique  employed  depends  on  the  algorithm  used.  Algorithms  are  assumed  to  be  bilaterally 
agreed  or  registered  by  a  registration  authority.  However,  the  algorithm-identifier  must  be  unique  and 
unambiguously  define  the  algorithm. 

It  is  recommended  that  a  conforming  ASN.1  BIT  STRING  is  normally  used  to  contain  the  encrypted  data  (as 
generated  by  use  for  the  ENCRYPTED  macro),  thereby  ensuring  insertion  of  padding  zero  bits  which  may 
be  necessary  for  correct  operation  of  certain  algorithms.  Alternatively,  the  implementation  should  take  such 
action  explicitly. 

It  is  recommended  that,  in  the  absence  of  any  requirement  for  support  of  other  specific  algorithms, 
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implementations  sliall  as  a  default  support  algorithms  identified  in  CCITT  X.509  (I  SO/I  EC  9594-8).  It  is  also 
strongly  recommended  that  implementations  are  capable  of  using  any  encryption-based  technique  on  a 
"plug-in"  or  modular  basis. 

In  the  case  of  verification  of  SIGNATURES  (e.g.,  proof  of  delivery,  MOAC,  POAC,  or  ROAC),  implementations 
should  assume  that  all  relevant  data  present  in  the  subject  message,  probe,  or  report  has  been  included  in 
the  signature. 


E.3.5       Implementation  Considerations 


E.3.5.1         Peer  Entity  Authentication 

Peer  entity  authentication  is  provided  using  the  strong  authentication  mechanisms  on  the  various  Bind 
operations,  using  either  asymmetric  or  symmetric  techniques.  The  key  management  information  necessary 
for  symmetric  peer  entity  authentication  is  outside  the  scope  of  these  Implementation  Agreements. 


E.3.5.2  Confidentiality 

Connection  confidentiality  is  provided  using  the  underlying  OSI  layers  and  is  outside  the  scope  of  these 
Implementation  Agreements.  Mechanisms  to  support  connection  confidentiality  are  subject  to  bilateral 
agreement  between  peers  (i.e.,  connection  confidentiality  may  even  be  achieved  by  trusting  the  connection 
to  the  peer  OSI  entity). 

Content  Confidentiality  may  be  achieved  by  either  symmetric  or  asymmetric  encryption  techniques.  It  should 
be  noted  that  use  of  asymmetric  techniques  precludes  submission  of  messages  to  multiple  recipients. 

E.3.5.3  Integrity 

Connection  Integrity  is  provided  using  the  underlying  OSI  layers  and  is  outside  the  scope  of  these 
Implementation  Agreements.  Mechanisms  to  support  Connection  Integrity  are  subject  to  bilateral  agreement 
between  peers.  It  should  be  noted  that  the  integrity  of  a  connection  can  be  increased  by  use  of  RTSE. 

Content  Integrity  is  achieved  by  computing  a  content  integrity  check  as  a  function  of  the  entire  message 
content.  When  symmetric  techniques  are  used  to  compute  the  content  integrity  check  a  secret  key  is 
required.  This  content  integrity  key  may  be  confidentially  sent  to  the  message  recipient  using  the  message 
argument  confidentiality  security  element  in  the  message  token  (i.e.,  there  may  be  other  keys  or  parts  of  the 
key  not  sent  by  the  originator  with  the  message,  but  the  key  management  of  such  external  keys  is  outside 
the  scope  of  these  Implementation  Agreements).  It  should  be  noted  that  placing  the  content  integrity  check 
in  the  encrypted  data  of  the  message  token  will  provide  additional  protection  against  masquerade  threats. 

NOTE  -  Content  Integrity  can  also  provide  integrity  of  receipt  and  non-receipt  notifications  (IPNs)  and  can 
assist  in  the  provision  of  "non-repudiation  of  receipt"  since  non-repudiation  of  delivery  may  be  insufficient  where 
delivery  is  to  a  Message  Store. 
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E.3.5.4 


Message  Origin  Authentication 


End-to-end  (i.e.,  UA  to  UA)  Message  Origin  Authentication  is  automatically  provided  by  content  integrity. 
Security  classes  S2  and  S2a  provide  additional  protection  (i.e.,  of  the  integrity  of  the  label)  by  requiring 
support  of  origin  authentication  checks  within  the  MTS. 


If  asymmetric  techniques  are  used  for  content  integrity  it  can  also  provide  non-repudiation  of  origin  (UA  to 
UA)  depending  on  the  level  of  trust  placed  in  the  certificate.  If  symmetric  techniques  are  used,  content 
Integrity  can  also  provide  non-repudiation  of  origin,  but  only  by  using  a  trusted  notary  to  validate  the  content 
integrity  and  provide  trusted  key  management  facilities.  A  degree  of  non-repudlcation  can  be  provided  by 
the  use  of  trusted  accountability  services. 

NOTE  -  It  is  assumed  that  an  originating  UA  will  ensure  that  delivery  notification  is  requested  when  proof  of 
delivery  is  requested. 


Secure  Access  Management  can  be  implemented  by  a  combination  of  Multi-Level  Security  (MLS) 
functionality  by  assurance  of  the  various  MHS  components  to  support  such  functionality.  MLS  functionality 
is  supported  in  the  base  standards  by  the  use  of  security  labels,  security  context  and  the  security  token  and 
can  be  applied  In  a  hierarchical  and/or  role  manner  depending  on  the  policy  requirements  of  a  domain. 

MLS  assurance  will  generally  also  require  other  (COMPUSEC)  measures  and  is  outside  the  scope  of  the 
base  standards  and  these  Implementation  Agreements.  Reference  should  be  made  to  the  appropriate 
security  authority  and  any  applicable  security  evaluation  criteria  (e.g.,  U.  S.  DoD  Orange  Book,  UK  - 
Netherlands  -  Germany  -  France  draft  Evaluation  Criteria). 


E.3.5.7        Implications  for  the  Use  of  Distribution  Lists 

An  MTA  performing  distribution  list  expansion  must  create  all  the  per-recipients  fields  for  the  members  of 
the  distribution  list.  It  may  either  generate  a  new  token  for  each  DL  member  (i.e.,  using  the  recipient  name 
of  that  DL  member)  or  alternatively  it  may  copy  the  same  token  (i.e.,  containing  the  recipient  name  of  the 
DL  Itself)  into  the  per-recipient  fields  for  each  DL  member.  In  the  former  case,  the  content-integrity-check 
should  not  be  changed  if  it  is  to  be  used  to  provide  message  origin  authentication.  Also  in  such  case,  the 
DL  expansion  point  must  have  at  least  the  same  security  class  as  the  originator  and  must  have  trusted 
functionality.  The  choice  of  which  approach  to  use  will  therefore  need  to  be  determined  in  accordance  with 
the  security  policy  which  may  prohibit  the  use  of  distribution  lists  altogether. 


E.3.5.8        Implications  on  Redirection 

The  Security  Functional  Group  has  the  effect  of  either  requiring  trust  in  any  redirection  facilities  or  prohibiting 
the  use  of  redirection.  If  the  Redirection  facility  is  to  be  trusted,  it  must  be  subject  to  the  security  policy  and 
obey  the  security  labels  as  defined  in  the  base  standards.  It  is  recommended  that  the  token  is  not  altered 


E.3.5.5 


Non-Repudiation 


E.3.5.6 


Secure  Access  Management 
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on  redirection  (i.e.,  it  will  contain  the  originally-specified  recipient  name). 


E.3.5.9        Implications  for  1984  interworking 

IntenA/orking  between  implementations  conforming  to  Security  Functional  Groups  and  1984  systems  is  not 
supported.  The  Double  Enveloping  technique  can  be  used  to  traverse  an  1984  system. 


E.3.5.10       Implications  for  Use  Of  Directory 

The  X.400  security  services  use  of  the  directory  service  does  not  require  a  trusted  directory  because  the 
information  that  is  retrieved  is  certified  and  can  be  validated  independently  of  the  directory. 

Other  threats  (e.g.,  malicious  corruption  of  directory  information)  may  arise  from  the  broader  use  of  the 
directory,  however  these  are  outside  of  the  scope  of  the  X.400  base  standard  and  this  Implementors 
Agreement. 

Work  continues  within  CCITT  and  ISO  to  improve  the  security  inherent  in  the  Directory  standards. 


E.3.5.11       Implications  for  Conversion 

Implementation  of  the  Security  functional  group  may  additionally  either  require  that  any  conversion  facilities 
are  highly  trusted  to  regenerate  the  appropriate  security  elements  (notably  the  content  integrity  check)  or 
prohibit  the  use  of  conversion  within  the  MTS  altogether.  In  particular,  it  should  be  noted  that  use  of 
conversion  facilities  will  invalidate  any  origin  authentication  based  on  the  original  content. 


E.3.5.12  Accountability 

Accountability  depends  on  the  identification  and  authentication  of  users,  then  subsequent  records  being  kept 
on  the  actions  taken  by  users.  Therefore,  accountability  depends  on  all  the  relevant  information  being 
properly  stored  or  recorded. 

Accountability  features  provided  by  domains  (or  MTAs)  are  subject  to  bilateral  agreement  between  domains 
(or  MTAs)  and  may  optionally  provide  non-repudiation  services.  Accountability  features  include  pervasive 
mechanisms  such  as  security  logs,  audit  trails  and  archives,  or  they  may  be  mechanisms  supported  by 
protocol.  Protocols  to  support  accountability  will  be  subject  to  bilateral  agreement. 


E.3.5.13       Double  Enveloping 

Double  enveloping  can  be  used  with  each  secure  messaging  security  class.  For  each  security  class  it  is  an 
optional  extension  to  the  security  features  which  can  be  used  to  counter  specific  vulnerabilities.  When 
double  enveloping  is  used,  it  shall  be  applied  at  the  boundary  of  a  domain,  and  obey  the  rules  of  an  MTA 
at  management  domain  boundaries.  Figure  24  illustrates  the  technique. 
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Outer  Envelope  2 


Content  2 


Inner  Envelope  1 

Content  1 

Figure  24  -  Double  enveloping  technique 

Address  information  in  envelope  1  and  2  are  not  necessarily  tfie  same. 
Trace  information  in  envelope  1  and  2  are  not  necessarily  the  same. 

The  double  envelope  technique  can  be  used  in  1984  and  1988  MTS  environments.  When  used  in  an  1988 
environment,  any  security  class  can  be  applied  to  the  outer  envelope.  It  is  recommended  that  the  inner 
envelope  is  encrypted.  When  the  double  envelope  technique  is  used  as  a  secure  relay  path  via  an  1984 
domain,  any  encryption  of  the  content  2  is  subject  to  bilateral  agreement. 

Trace  information  is  not  passed  between  inner  and  outer  envelopes.  It  is  recommended  that  trace 
information  on  the  outer  envelope  is  always  archived  when  the  double  envelope  technique  is  used. 

E.4      Security  Class  SO 
E.4.1  Rationale 

Security  class  SO  is  confined  to  security  functionality  operating  between  MTS-Users  on  an  end-to-end  basis. 
It  is  designed  to  minimize  the  required  functionality  in  the  MTS  to  support  submission  of  elements  associated 
with  these  services.  Security  services  which  must  be  supported  (i.e.,  must  be  made  available)  are  those 
which  are  considered  in  any  secure  messaging  environment,  i.e.: 

a)  Content  Integrity; 

b)  Message  Origin  Authentication  (end-to-end); 

c)  Proof  of  Delivery. 

Other  security  services,  such  as  Content  Confidentiality,  may  optionally  be  supported. 
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E.4.2       Technical  Implications 

The  technical  implications  for  security  class  SO  are: 

a)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  generate  the  signed,  signature  and 
encrypted  macros  on  message  submission;  and, 

b)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  handle  the  signed,  signature  and 
encrypted  macros  on  message  delivery. 


E.5      Security  Class  SI 


E.5.1  Rationale 

The  S1  security  class  is  a  superset  of  security  class  SO  and  introduces  the  basic  requirement  for  security 
functionality  not  only  within  the  MTS-User  but  also  within  the  MTS.  This  security  functionality  within  the  MTS 
is  designed  to  support  the  enforcement  of  a  security  policy  within  a  security  domain.  As  a  consequence, 
S1  enables  trusted  routing  to  be  implemented. 

NOTE  -  The  level  of  trust  in  the  route  will  depend  on  the  level  of  trust  in  the  security  label  and  security  context. 


E.5.2       Technical  Implications 

The  technical  implications  of  security  class  S1  are: 

(       a)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  generate  the  signed,  signature  and 
encrypted  macros  on  message  submission; 

b)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  handle  the  signed,  signature  and 
encrypted  macros  on  message  delivery; 

c)  It  is  necessary  to  provide  mechanisms  in  the  MTA  for  registration,  change-credentials  and  bind 
abstract  operations  (i.e.,  signed  macro  for  bind); 

d)  It  is  necessary  to  provide  mechanisms  in  the  MS  for  MS-registration  and  MS-bind  operation  (i.e., 
signed  macro  for  MS-Bind); 

e)  It  is  necessary  to  support  message  security  labelling  (the  level  of  assurance  is  subject  to 
individual  security  domain  requirements); 

f)  It  is  necessary  that  reliable  access  is  always  supported; 

g)  It  is  necessary  for  the  MTAs  to  check  the  existence  of  the  security  elements  which  are  classified 
as  "dynamic  mandatory"; 
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h)  It  is  necessary  to  provide  a  trusted  connection  between  peers  to  provide  adequate 
confidentiality,  integrity  and  peer  entity  authentication. 


E.6      Security  Class  S2 


E.6.1  Rationale 

Security  Class  S2  is  a  superset  of  Security  Class  SI .  It  enhances  the  facilities  of  the  MTAs  in  order  to  check 
the  origination  of  messages,  probes,  and  reports  within  the  MTS  and  to  provide  enhanced  integrity  checks 
on  the  security  label  while  in  the  MTS.  The  extra  security  services  provided  by  this  security  class  can  help 
to  provide  trusted  routing  within  an  MTS. 

Additionally,  it  is  possible  to  provide  non-repudiation  within  an  MTS. 


E.6.2       Technical  Implications 

The  extra  security  services  specified  by  Security  Class  S2  use  asymmetric  techniques  exclusively. 
The  technical  implications  are  as  in  Security  Class  S1,  plus: 

a)  It  is  necessary  to  provide  mechanisms  in  an  MTA  and  UA  that  can  process  the  signed  macro 
of  certificates; 

b)  The  constraint  that  the  option  of  supporting  Content  Confidentiality  cannot  be  allowed  when  the 
message  origin  authentication  check  (MOAC)  is  used  to  provide  non-repudiation  services.  Under 
this  condition  Content  Confidentiality  is  not  supported.  If  the  MOAC  is  not  used  for  this  purpose. 
Content  Confidentiality  can  be  supported  as  an  optional  security  service; 

c)  It  is  necessary  to  provide  mechanisms  in  a  MTA  which  can  generate  and  process  the  signature 
macro  of  a  message,  probe,  and  report  authentication  check  (MOAC,  POAC  and  ROAC); 

d)  It  is  necessary  to  provide  mechanisms  in  a  UA  and  MTA  that  can  interface  with  an  X.500 
directory  supporting  the  Authentication  Framework  as  defined  in  X.509/ISO  9594-8  or  can  distrubute 
public  keys  by  other  trusted  means  which  is  compliant  with  X.509; 

e)  It  is  necessary  to  provide  a  trusted  means  of  generating  certificates; 

f)  It  is  necessary  to  provide  mechanisms  in  the  MTA  which  can  process  a  proof  of  submission 
request  and  generate  the  proof  of  submission  signature; 

g)  It  is  necessary  to  provide  a  mechanism  in  an  MTA  which  will  generate  ROAC  signatures  with 
reports; 

h)  Connection  confidentiality  is  only  provided  by  this  security  class  when  the  message-origin- 
authentication-check  is  computed  using  clear  content  to  provide  non-repudiation  of  origin  security 
service  (i.e.,  non-repudiation  is  provided  only  on  the  clear  content  of  the  message); 
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i)  The  irrevocable  proof  required  to  provide  non-repudiation  within  the  MTS  is  achieved  by  the 
management  of  asymmetric  keys.  The  explicit  definition  of  asymmetric  key  management  is  outside 
the  scope  of  these  Implementors  Agreements. 


E.7      Confidential  Security  Class  Variants  (SOa,  S1  a,  and  S2a) 


E.7.1  Rationale 

These  security  class  variants  are  supersets  of  SO,  S1 ,  and  S2,  adding  the  requirement  for  support  of  end-to- 
end  content  confidentiality.  The  rationale  for  these  variants  is  to  avoid  the  implementation  cost  and 
processing  overhead  involved  in  encrypting  the  entire  message  content  unless  there  is  a  definite 
requirement.  It  is  also  possible  to  protect  the  encryption  techniques  and  mechanisms  (i.e.,  algorithms,  key 
lengths,  key  versions,  etc.)  by  Secure  Access  Management. 


E.7.2       Technical  Implications 

The  technical  implications  of  the  confidential  security  class  variants  are  the  same  as  those  for  the 
corresponding  primary  security  class,  plus: 

a)  It  is  necessary  to  provide  mechanisms  in  a  UA  which  can  use  the  encrypted  macros  to  encrypt 
and  decrypt  the  message  content. 
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this-ipm-prefix  78 
this-recipient-name  70 
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auto-forwarded  98 
bilaterally-defined-body-parts  98 
blind-copy-recipients  98 
body  98 

child-sequence-numbers  95 
commonName  22 
content  95 

content-confidentiality-algorithm-identifier  95, 97 

content-correlator  95 

content-identifier  95 

content-integrity-check  95,  97 
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NOTE  -  In  document  type  names,  constraint  set  names,  and  abstract  syntax  definitions,  the  "NBS"  designation 
will  be  preserved. 


0  Introduction 

This  part  defines  Implennentors'  Agreennents  based  on  ISO  File  Transfer,  Access  and  Management  (FTAM), 
as  defined  in  ISO  8571.  This  International  Standard  has  four  parts.  Part  1  of  the  IS  gives  general  concepts, 
part  2  defines  the  Virtual  Filestore  (VFS),  part  3  defines  the  File  Service,  and  part  4  defines  the  File  Protocol. 

FTAM,  as  described  in  the  IS,  is  based  on  the  following  ISO  documents:  ACSE  Service  and  Protocol  (ISO 
8649,  ISO  8650),  Presentation  Service  and  Protocol  (ISO  8822,  ISO  8823),  ASN.1  Abstract  Syntax  Notation 
and  Basic  Encoding  Rules  (ISO  8824,  ISO  8825),  and  Session  Service  and  Protocol  (ISO  8326,  ISO  8327). 
These  services  and  protocols  are  defined  architecturally  in  the  OSI  Reference  Model  (ISO  7498).  These 
Agreements  provide  detailed  guidance  for  the  implementor,  and  eliminate  ambiguities  in  interpretations. 

The  general  agreements  reached  with  respect  to  the  ISO  File  Transfer,  Access  and  Management  Protocol 
(FTAM)  are  that  the  Phase  2  FTAM  specification  (this  part)  is  based  on  the  International  Standard  (IS). 


1  Scope 

These  FTAM  Phase  2  Agreements  cover  transfer  of  and  access  to  files  between  the  Filestores  of  two  end 
systems,  including  the  management  of  a  Virtual  Filestore.  One  end  system  acts  in  the  Initiator  role  and 
initiates  the  file  transfer/access,  while  the  other  end  system  acts  in  the  Responder  role  and  provides  access 
to  the  file  in  the  Virtual  Filestore.  This  part  describes  Agreements  for  the  actions  and  attributes  of  the  Virtual 
Filestore,  and  the  service  provided  by  the  file  service  provider  to  file  service  users,  together  with  the 
necessary  communications  between  the  Initiator  and  Responder. 


virtual 
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2 


Real 
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End 
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End 
System  2 
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Figure  1  -  Model  of  file  transfer/access. 


NOTE  -  Agreements  apply  on  the  double  lines  of  figure  1.  The  mapping  between  the  Virtual  Filestore  and 
the  Real  Filestore  together  with  the  local  data  management  system  is  not  part  of  these  Agreements. 


These  Agreements  define  general  Agreements  in  clauses  5  through  16,  minimum  functionality  (Conformant 
Implementations)  in  clause  17,  and  functionality  for  several  Implementation  Profiles  which  are  tailored  to 
different  classes  of  user  requirements  in  clauses  18  and  19. 
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8571-2:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  Management  Part  2:  Virtual  Filestore  Definition  ISO 

ISO  8571-3:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  3:  The  File  Service  Definition 

ISO  8571-4:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  4:  The  File  Protocol  Specification 


3  Status 

Version  3  of  the  FTAM  Phase  2  Implementation  Agreements  was  completed  December  15,  1989,  and 
published  in  version  3  of  the  Stable  Implementation  Agreements  (NIST  Special  Publication  500-177, 
December  1989).  Some  editorial  clarifications  and  technical  changes  (due  to  international  harmonization 
of  Profiles)  were  added  to  Version  3  Agreements  in  the  course  of  1 990.  All  these  changes  are  now  fully 
incorporated  in  this  version  4  of  the  FTAM  Phase  2  Stable  Agreements. 

No  further  enhancements  will  be  made  to  this  version  4  of  FTAM  Phase  2  (see  the  clause  4  ERRATA). 

This  version  4  of  the  FTAM  Phase  2  Agreements  fully  replaces  the  version  3  as  published  in  NIST  SP  500- 
177.  Therefore,  the  old  version  3  of  RAM  Phase  2  will  no  longer  be  maintained. 

The  following  list  summarizes  the  technical  errata  changes  to  FTAM  Phase  2,  Version  1  which  were 
incorporated  in  Version  2.  It  also  states  the  degree  of  possible  interworking  and  bacl<ward  compatibility  to 
FTAM  Phase  2,  Version  1. 


Technical  Changes  in  FTAM  Phase  2, 
Version  2  (Dec.  '88) 

Backward  Compatibility  to  FTAM 
Phase  2,  Version  1  (Dec.  '87) 

1 .  Check  of  already  established 
presentation  contexts  for  a 
document  type  not  at  CREATE 
time  but  at  OPEN  time 

Interworking  problems  could  occur  when 
creating  a  document  type  which  is  not 
opened 

2.  Receivers  shall  not  require 
sending  of  AETtitles 

Interworking  problems  could  occur  if 
AETities  are  not  sent 

3.  Minimum  requirement  for  FADU 
identities  for  document  types 
which  use  the  sequential  flat 
constraint  set 

Interworking  problems  could  occur  if  FADU 
identities  beyond  the  minimum  requirement 
are  used 
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The  following  list  summarizes  the  technical  errata  and  alignment  changes  which  were  incorporated  in  FTAM 
Phase  2,  Version  3.  It  also  states  the  degree  of  possible  interworking  and  backward  compatibility  to  FTAM 
Phase  2,  Version  2. 


Technical  Changes  in  FTAM  Phase  2, 
Version  3  (Dec.  '89) 

Backward  Compatibility  to  FTAM 
Phase  2,  Version  2  (Dec.  '88) 

1.  Unconstrained  Service  Class  outside 
the  scope  of  the  Implementation 
Profiles 

Full  compatibility,  since  change  only  from 
"oDtional"  "to  "outside  scone" 

2.  <  contents-type-list  >  parameter: 
Both  types  of  values  optional 
for  Initiators 

Full  compatibility,  since  this  clarification  is 
only  for  Initiators 

3.  Specification  of  supported  values  for 
<  override  >  parameter  in  F-CREATE 

Interworking  problems  may  occur,  if  different 
values  supported 

4.  Parameters  <filesize>,  <  future 
filesize>,  <fadu-number>  maybe 
encoded  with  up  to  8  contents 
octets 

Interworking  problems  may  occur,  since  no 
minimum  requirement  was  defined  for 
Version  2. 

5.  For  NBS-7  and  NBS-8  in 
conjunction  with  T  or  TM 
Service  Class,  the  FADU 
identities  "current",  "next", 
"previous"  are  not  required 

Full  compatibility,  since  these  identities  were 
never  useful  in  conjunction  with  T  or  TM 
Service  Class 

6.  For  NBS-8  files  the  minimum  range 
for  keys  of  string-type  is  (1-16) 
instead  of  (0-16) 

Interworking  problems  may  occur  for  key- 
length  parameter  0 

7.  Restriction  "NBS-9  files  may  not  be 
Created  or  Deleted"  removed  from 
the  document  type  definition.  But 
both  actions  are  outside  the  scope  of 
the  Agreements. 

Full  compatibility,  since  Creation,  Deletion 
was  never  in  the  scope  of  the  Agreements 

8.  Constraint  set  NBS-ordered-flat: 
The  location  after  an  Insert  is  "end" 

Full  compatibility,  since  this  specification  was 
already  implicitly  clear 
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4  Errata 


NO.  OF 
ERRATA 

TYPE 

REFERENCED 
DOCUMENT 

CLAUSE 

CP  3/91-1 

EDITORIAL 

NIST-SP  500-183 

All 

Update  to  ISO  style. 
General  formatting  and 
error  corrections. 
Alignment  with  the 
wording  of  the  ISP. 
Consistent  naming 
conventions. 

CP  9/91-1 
CP  9/91-2 

EDITORIAL 

NIST-SP  500-183 

Table  9 
Table  10 
Table  1 1 

Datatype  1  AS  N.I 
comment  to  use  the 
object  descriptor 

CP  9/91-3 
CP  9/91-4 

Clause  17 
Annex  A 

Include  Corrigenda 

Editors  note  to  point  at 
ISP  for  registered 
objects. 

CP  9/91-5 

CP  9/91-6 

A.5.11.1 
A.6.11.1 

A.7.7 
A.7.9.1 
A.7.9.2 

Change  header  to 
Structural  Simplification. 

Added  definitions  for 
Datatypes 

5  Assumptions 

FTAM  protocol  machines  must  be  able  to  parse  and  process  at  a  minimum  7K  octets  of  FTAM  PCI,  FTAM 
structuring  (FTAM-FADU)  and  FTAM  user  data  (including  grouped  FPDUs)  as  they  would  be  encoded  with 
theASN.1  Basic  Encoding  Rules.  It  is  recommended,  however,  that  Presentation  user  data  not  be  restricted 
in  size. 

In  order  to  maximize  interoperability,  it  is  important  that  the  implementations  of  FTAM  service  providers  do 
not  unnecessarily  restrict  the  service  user's  ability  to  generate  arbitrary  file  service  requests.  Otherwise,  they 
may  not  be  able  to  work  with  FTAM  Responders  whose  operation  is  constrained  by  their  mapping  of  the 
RAM  Virtual  Filestore  to  their  local  filestore.  For  example,  error  procedures  should  only  be  invoked  when 
an  error  actually  occurs,  not  at  the  point  of  the  specification  of  options  which  might  result  in  an  error. 

Implementations  must  be  able  to  parse  all  valid  optional  parameters  if  they  are  present  in  the  PDU.  Only 
those  optional  parameters  specified  as  supported  in  these  Agreements  are  required  to  be  implemented.  If 
these  parameters  are  not  present,  a  default  value  is  assigned  locally.  A  Responder  should  not  refuse  a 
request  solely  because  a  parameter  that  is  optional  in  the  FTAM  standard,  but  is  supported  in  these 
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Agreements,  is  not  present. 

Consideration  of  any  standardized  service  interface  is  not  covered  by  these  Agreements. 

TInese  Agreements  define  no  restrictions  for  the  values  used  for  the  <  communication  quality  of  service > 
parameter  in  <F-INITIALIZE>. 

FTAM  is  defined  in  phases.  The  Phase  1  FTAM  implementation  specification  is  based  on  the  second  ISO 
Draft  Proposal,  dated  April  1985,  and  the  ISO  Draft  Proposal  8824  and  8825. 

The  Phase  2  FTAM  specification  (this  part)  Is  based  on  the  International  Standard  (IS).  THERE  IS  NO 
BACKWARD  COMPATIBILITY  WITH  FTAM  PHASE  1.  Backward  compatibility  Is  impossible,  since  Phase 
1  uses  Session  services  directly,  while  Phase  2  uses  ACSE  and  Presentation  services.  Furthermore,  there 
are  differences  In  Filestore,  PDU  Abstract  Syntax,  FADU  Abstract  Syntax,  and  Transfer  Syntax.  There  also 
are  differences  in  the  transparency  mechanisms  and  service  class  negotiations. 

The  < implementation  information >  parameter  of  <F-INITIAUZE>  FPDU  as  defined  in  ISO  8571-4,  20.3  is 
used  to  pass  'user  version'  information  with  respect  to  different  FTAM  phases  of  the  OSI  Implementors' 
Agreements  or  with  respect  to  FTAM  profiles  of  other  bodies  (see  clause  12).  It  is  the  goal  of  these 
Agreements  to  use  the  'user  version'  mechanism  to  provide  at  least  one  level  of  backward  compatibility  for 
all  future  FTAM  Phases,  facilitating  backward  compatibility  for  future  FTAM  products,  assuming  different  new 
versions  of  the  respective  IS's  also  enable  backward  compatibility. 

The  FTAM  specific  ASE  requirements  for  ACSE  in  the  Upper  Layers  part  of  this  document  define  a  value 
(that  carries  no  semantics)  for  the  AETitle  that  can  be  used  by  FTAM  ASEs  for  communication.  Other  values 
for  the  AETitle  are  outside  the  scope  of  these  Agreements. 

The  association  shall  not  be  rejected /aborted  If  any  of  the  following  parameters  either  contains  the  defined 
value  or  is  not  sent: 

Called  -  AETitle 

Calling  -  AETitle 

Responding  -  AETitle 

The  association  may  be  rejected /aborted  if  any  of  these  parameters  contain  other  values. 

Use  of  values  outside  the  scope  of  these  Agreements  is  discouraged  until  agreed  upon  semantics  have  been 
associated  with  AETitles. 

Use  of  <  shared  ASE  Information  >  parameter  and  <  charging  >  parameter  Is  not  defined  within  the  scope 
of  the  Agreements. 

Use  of  < application  context  name>  parameter  is  not  defined  within  the  scope  of  these  Agreements.  This 
parameter  does  not  prohibit  the  establishment  of  an  FTAM  association. 

These  Agreement  use  the  term  'supported'  for  a  parameter  to  mean  that  the  syntax  and  semantics  of  that 
parameter  shall  be  implemented.   However,  it  is  not  a  requirement  that  the  parameter  be  used  in  all 
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instances  of  communication,  unless  stated  otherwise. 

Also  these  Agreements  use  the  term  'optionally  supported'  for  a  parameter  to  mean  that  it  is  left  to  the 
implementation  whether  the  semantics  of  that  parameter  are  implemented  or  not. 

6  Presentation  agreements 

The  following  Abstract  Syntaxes  are  recognized  in  these  Agreements: 
"FTAM  FADU" 
"FTAM  PCI" 

"FTAM  unstructured  text  abstract  syntax" 

"FTAM  unstructured  binary  abstract  syntax" 

"NBS  abstract  syntax  AS1" 

"NBS  file  directory  entry  abstract  syntax" 
The  following  Transfer  Syntax  is  supported: 

"Basic  Encoding  of  a  single  ASN.1  type" 
See  also  annex  C. 

7  Service  class  agreements 

Implementation  Agreements  have  been  reached  for  the  following  service  classes: 
File  Transfer 
File  Access 
File  Management 
File  Transfer  and  Management 
Unconstrained 
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8  Functional  unit  agreements 

Implementation  Agreements  have  been  reached  for  the  following  functional  units: 
Kernel 
Read 
Write 

File  Access 

Limited  File  Management 
Enhanced  File  Management 
Grouping 

Implementation  of  the  Recovery,  Restart  Data  Transfer,  and  FADU  Locking  functional  units  is  not  specified. 

9  File  attribute  agreements 

Implementation  of  the  Kernel  Group  of  file  attributes  is  defined.  If  the  optional  Storage  Group  and  Security 
Group  are  implemented,  aspects  of  their  implementation  are  defined.  Implementation  of  the  Private  Group 
is  not  specified. 

Responses  to  an  attribute  value  request  shall  always  include  one  of  the  following  (as  specified  in  ISO  8571  -2, 
clause  4): 

An  actual  file  attribute  value. 

A  value  indicating  that  no  value  is  available,  optionally  with  a  diagnostic. 

No  value  and  an  error  code,  optionally  with  a  diagnostic  indicating  that  the  attribute  is  not 
supported. 

9.1      Mandatory  group 

Only  the  Kernel  Group  of  attributes  is  required.  A  value  for  < filename  >,  <  permitted  actions  >,  and 
<  contents  type>  will  always  be  available. 

A  minimum  range  is  required  for  <filename>  values  as  specified  in  ISO  8571-2.  No  maximum  length  or 
format  restrictions  apply.  A  system  that  does  not  support  < filename >  values  with  a  sequence  of  more  than 
one  Graphic  String  or  extended  <filename>  characteristics  may  reject  a  request  involving  such  a 
<filename>.  All  systems  must  be  able  to  interpret  a  <filename>  value  with  a  sequence  of  one  Graphic 
String. 
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A  Responder  shall  not  require  an  Initiator  to  use  multiple  component  Graphic  String  filenames.  Requests 
using  a  single  component  < filename  >  value  with  a  sequence  of  one  Graphic  String  shall  be  responded  to 
using  a  single  component  <filename>  value.  Responses  to  requests  involving  <filename>  values  having 
two  or  more  Graphic  Strings  are  not  defined  here  but  may  be  interpreted  via  bilateral  or  other  external 
agreements.  Use  of  < filename >  values  with  a  sequence  of  more  than  one  Graphic  String  is  discouraged. 

Apart  from  the  minimum  conformance  requirements  specified  in  ISO  8571-2.  file  names  have  to  be  specified 
in  the  naming  convention  of  the  responding  FTAM  implementation.  It  is  a  local  implementation  matter  of 
the  FTAM  Responder,  whether  or  not  an  additional  name  mapping  onto  the  real  Filestore's  file  name 
convention  is  supported. 

In  order  to  enable  interworking  with  all  FTAM  Responders'  virtual  Filestores,  it  is  recommended  that  FTAM 
Initiators  impose  no  restrictions  on  the  attribute  range  supported  for  file  names  beyond  those  specified  in 
ISO  8571-2. 

For  the  purpose  of  interworking  according  to  these  Agreements  the  <  contents  type>  attribute  is  limited  to 
the  <  document  type  name>  format.  The  <  constraint  set  name,  abstract  syntax  name>  form  is  outside  the 
scope  of  these  Agreements.  It  should  always  be  parsed  correctly  when  received,  but  may  result  in  an  error. 


9.2      Optional  groups 

If  the  optional  Security  Group  of  file  attributes  is  implemented,  an  actual  value  must  be  available  for  the 

<  access  control  >  attribute. 

The  <  access  control  >  attribute  is  a  SET  OF  <  access  control  element  >.  The  minimum  requirement  in  these 
Agreements  is  the  support  of  one  <access  control  element>,  according  to  the  base  standard.  The  terms 

<  concurrency  access  >,  <  identity  >,  and  <passwords>  are  each  optionally  supported.  Details  of  their  use 
shall  be  specified  in  the  PICS.  Use  of  the  <  location  >  term  is  not  specified  in  these  Agreements. 

Implementation  of  the  Private  Group  is  not  specified. 


10  Document  type  agreements 


These  document  types  are  defined: 


FTAM-1 


ISO  FTAM  unstructured  text' 


FTAM-2 


ISO  FTAM  sequential  text" 


bnf?. 


FTAM-3 


ISO  FTAM  unstructured  binary' 


NBS-6  "NBS-6  FTAM  sequential  file' 


NBS-7  "NBS-7  FTAM  random  access  file' 


NBS-8  "NBS-8  FTAM  indexed  file' 
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NBS-9  "NBS-9  Fn"AM  file  directory  file" 

Detailed  document  type  definitions  are  given  in  annex  A  and  in  ISO  8571  -2,  annex  B. 

NOTE  -  Document  types  NBS-1  to  NBS-5  are  not  defined  in  these  Agreements.  The  numbering  starts  with 
NBS-6  because  of  the  original  DIS  version  of  these  Agreements. 

An  implementation  claiming  conformance  to  these  Agreements  which  also  supports  any  or  all  of  the 
document  types  FTAM-1,  FTAM-2,  and  FTAM-3  as  defined  in  ISO  8571-2,  annex  B,  must  minimally  support 
the  combinations  of  parameter  values  as  specified  in  table  1 


TabSe  1  -  Parameters  for  FTAM-1,  -2,  -3 


Universal 

Maximum 

String 

Class  Number 

String  Length*"' 

Significance 

FTAM-1 

General  String  ^(27) 
lASString  ^(22) 

134  or  less 

'not-significant'® 

ITAM-2 

Graphic  String  ^'"(25) 

134  or  less^ 

'not-significant'® 

FTAM-3 

<not  applicable  > 

512  or  less 

'not-significant"* 

NOTES 

1  The  minimum  level  of  support  for  General  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO 
and  G1  character  sets,  and  ISO  646,  IRV  CO  set. 

2  The  support  for  IA5  String  is  the  ISO  646,  IRV  GO  character  set  and  the  ISO  646,  IRV  CO  set. 

3  The  minimum  level  of  support  for  Graphic  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO 
and  G1  sets. 

4  This  is  the  default  when  the  parameter  is  not  specified. 

5  The  implementation  need  not  support  Data  Units  whose  total  character  count  exceeds  134. 

6  As  per  table  3. 

7  The  length  refers  to  the  number  of  characters  from  the  applicable  character  set.  It  does  not  include  any 
escape  sequences  or  overhead  from  the  encoding. 

8  If  escape  sequences  are  used  in  the  encoding  of  the  data  and  string  boundaries  are  not  maintained  when 
the  file  is  stored,  it  may  be  necessary  for  the  escape  sequences  to  occur  at  different  locations  when  the  file 
is  re-sent. 

For  document  types  which  use  the  sequential  flat  constraint  set,  conformant  implementations  must 
minimally  support  FADU  identities  as  follows: 

for  Transfer  service  class:  'begin',  'end' 
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for  Transfer  and  Management  service  class:      'begin',  'end' 

for  Access  sen/ice  class:  'begin',  'end',  'first',  'next' 

For  the  document  types  NBS-7  and  NBS-8  used  in  conjunction  with  the  Transfer  sen/ice  class  or  the 
Transfer  and  Management  service  class,  the  support  of  the  FADU  identities  of  'current',  'next'  and  'previous' 
and  for  NBS-8  the  support  of  the  FADU  identity  of  'end'  are  outside  the  scope  of  these  Agreements. 

For  the  document  types  NBS-6,  NBS-7  and  NBS-8  parameters  are  used  for  which  the  Agreements  apply  as 
specified  in  table  2. 


Table  2  -  Parameters  for  NBS-6,  NBS-7,  NBS-8 


Parameter 

Prim  Type 

String-length 

Length-1 

Length-2 

int 

INTEGER 

Number  of  octets 
required  to  represent,  in 
2's  complement  format, 
the  largest  integer  to  be 
passed 

bit 

BIT  STRING 

Number  of  bits  in  string 
(non-varying) 

ia5 

IA5STRING 

Max  number  of 
characters  in  string 

graphic 

Graphic  String 

Max  number  of 
characters  in  string 

general 

General  String 

Max  number  of 
characters  in  string 

octet 

OCTET  STRING 

Max  number  of  octets  in 
string 

private-  class- 
number 

Floating  Point 
Number 

The  minimum 
number  of  bits 
required  to  be 
maintained  in  the 
mantissa  for  relative 
precision 

Number  of  bits 
required  to 
represent  the 
largest  unbiased 
integer  exponent 
in  2's  complement 

univer-time 

UTCTime 

<not  applicable > 

gen-time 

Generalized  Time 

<not  applicable  > 

boolean 

BOOLEAN 

<not  applicable  > 

null 

NULL 

<not  applicable  > 

NOTE  -  The  string  length  parameter  specifies  the  actual  number  of  from  the  referenced  character  set.  It  does 
not  include  any  escape  sequences  or  overhead  from  the  encoding. 
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The  primitive  data  types  and  minimal  size  ranges  that  an  implementation  must  accept  for  storage  are  given 
in  table  3. 


Table  3  -  FTAM  primitive  data  types 


Primitive  Data  Type 

Minimum  Range  (Octets) 

ASN.1  INTEGER 

1  -2 

ASN.1    BIT  STRING 

0-1 

ASN.1  lASString 

0-  134 

ASN.1  GeneralString 

0-  134 

ASN.1  GraphicString 

0-134 

ASN.1    OCTET  STRING 

0-512 

ASN.1  BOOLEAN 

ASN.1  NULL 

ASN.1  GeneralizedTime 

ASN.1  UniversalTime 

NBS-AS1  FloatingPointNumber 

mantissa  1-23  bits 

exponent  0-8  bits 

NOTES 

1  The  primitive  data  types  and  their  maximum  ranges  for  a  specific  file  as  described  by  the  parameters  above 
are  maintained  in  the  < contents  type>  file  attribute.  The  < contents  type>  file  attribute  value  is  established 
at  the  file's  creation  and  cannot  be  changed  via  FTAM  for  the  life  of  the  file.  This  implies  that  the  data  element 
types  and  ranges  and  data  unit  formats  are  fixed  for  all  accessors  of  that  file  as  long  as  the  file  exists. 

2  The  syntax  for  floating  point  numbers  is  part  of  the  definition  of  NBS  abstract  syntax  AS1  in  annex  C.3.  It 
is  derived  from  existing  standards  lEC  559  and  IEEE  754. 


10.1     Character  set 

Implementation  of  a  character  set  in  FTAM  is  understood  as: 
a  transfer  syntax  is  defined  for  the  character  set 

document  types  are  defined  using  the  character  set  in  their  abstract  syntactic  definition 

documents  of  those  types  are  stored  in  the  Virtual  File  Store  as  defined  in  the  character  set 
specification.  They  are  written  into  the  VFS  and  read  from  the  VFS  as  defined  by  the  abstract 
syntax  and  the  transfer  syntax  for  the  document  type.  It  is  not  in  the  scope  of  FTAM  Agreements 
to  specify  the  local  representation  of  those  documents  in  the  Real  Filestore,  nor  to  specify  rendition 
of  graphic  characters  or  control  characters  on  character  imaging  devices.  These  renditions  are 
possible  agreements  between  applications  using  FTAM  for  their  communication. 

The  character  sets  ISO  646,  IRV  and  ISO  8859-1  shall  always  be  implemented. 
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10.1.1      ISO  646  Character  set 

The  International  Reference  Version  (IRV)  of  ISO  646  is  available  for  use  when  there  is  no  requirement  to 
use  a  national  or  an  application-oriented  version.  In  information  interchange,  the  IRV  is  assumed  unless  a 
particular  agreement  exists  between  sender  and  receiver  of  the  data.  The  graphic  characters  allocated  to 
the  IRV  are  as  specified  in  table  4. 


Table  4  -  IRV  graphic  character  allocations 


Graphic 

Name 

Coded  Representation 

# 

Number  sign 

2/3 

o 

Currency  sign 

2/4 

@ 

Commercial  at 

4/0 

[ 

Left  square  bracket 

5/11 

\ 

Reverse  solidus 

5/12 

] 

Right  square  bracket 

5/13 

Circumflex  accent 

5/14 

Grave  accent 

6/0 

{ 

Left  curly  bracket 

7/11 

1 

Vertical  line 

7/12 

} 

Right  curly  bracket 

7/13 

Tilde,  overline 

7/14 

It  should  be  noted  that  no  substitution  is  allowed  when  using  the  IRV  and  that  the  facility  of  combined 
vertical  and  horizontal  movements  of  the  active  position  does  not  apply  to  any  format  effectors. 

It  is  permitted  to  use  composite  graphic  characters  and  there  is  no  limit  to  their  number.  Because  of  this 
freedom,  their  processing  and  imaging  may  cause  difficulties  at  the  receiving  end.  Therefore  agreement 
between  sender  and  receiver  of  the  data  is  recommended  if  composite  characters  are  used. 

NOTE  -  Attention  is  drawn  to  the  fact  that  different  national  character  sets  exist. 

(See  ISO  646  or  CCITT  Recommendation  T.50  for  more  information) 

10.1.2      Format  effectors 

When  a  single  format  effector  for  vertical  (or  horizontal)  movement  is  optionally  permitted  to  effect  a 
combined  vertical  and  horizontal  movement,  implementations  shall  not  use  the  single  format  effector  for 
effecting  the  combined  vertical  and  horizontal  movement.  It  is  recommended  that  OSI  Implementations  use 
<CR><LF>  pairs  as  line  terminators.    Failure  to  follow  this  recommendation  may  result  in  an 
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implementation  which  does  not  interoperate  with  other  implementations  conforming  to  these  agreements. 
NOTES 

1  For  further  information  see  ISO  646:1983,  clauses  4.1.22  and  6.4,  ISO  6429:1988,  clause  E.1.2  and  ISO 
4873:1986,  clause  A.3.2. 

2  The  Agreements  require  only  support  of  CO  control  characters  of  ISO  646,  containing  among  others  the 
format  effectors  <CR>  and  <LF>. 

10.1.3      8859-1  Character  set 

The  Latin  Alphabet  No.1  (ISO  8859-1)  is  used  to  specify  the  printable  characters  of  GO  and  G1.  CO  control 
characters  and  their  associated  rules  are  taken  from  the  ISO  646  definition. 

10.2    Document  type  Negotiation  rules 
10.2.1      Connection  establishment 

In  connection  establishment  the  <  contents  type  list>  parameter  is  used  only  to  establish  presentation 
contexts.  Both  the  <  document  type  name>  form  and  the  <  abstract  syntax  name>  form  are  supported  for 
Responders;  they  are  optionally  supported  for  Initiators. 
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10.2.2      File  creation 

An  <F-CREATE  request  >  FPDU  must  contain  a  < document  type  name>  value  in  its  <  initial  attributes > 
parameter. 

If  tiie  specified  document  type  requires  parameterization,  then  these  parameters  must  be  supplied,  otherwise 
the  <F-CREATE  request  >  may  be  rejected. 

NOTES 

1  It  is  understood  that  <  permitted  actions>  sub-field  of  <  initial  attributes>  parameter  will  always  be  used  at 
<F-CREATE  request>.  The  value  may  be  changed  by  the  Responder. 

2  If  the  <  document  type  name>  used  requires  DU  syntax  parameters  and  one  of  the  parameters  specifies 
'FloatingPointNumber'  as  a  primitive  data  type,  the  request  may  be  rejected,  in  case  the  optional  type 
'FloatingPointNumber*  is  not  supported  by  the  Responder. 


10.2.3      File  opening 

The  <  document  type  name>  form  (with  appropriate  parameters  as  specified  in  8871-2,  clause  12.3)  shall 
always  be  used  when  proposing  a  <  contents  type>;  as  an  alternative  the  'ContentsTypeUnknown'  value 
may  be  used  in  the  <F-OPEN  request >.  An  <F-OPEN  response  >  shall  use  the  <  document  type  name> 
option  (with  appropriate  parameters)  in  the  <  contents  type>  field. 

This  allows  the  receiving  entity  to  use  the  <  document  type  name>  attributed  to  the  file  instead  of  receiving 
a  <  constraint  set  name>  and  <  abstract  syntax  name>  pair,  which  does  not  reflect  the  file  information 
contained  in  the  FTAM  and  NBS  document  types. 

This  document  type  name  is  either  a  value  from  the  set  of  base  document  type  names  as  negotiated  upon 
connection  establishment  or  a  document  type  name,  for  which  an  appropriate  presentation  context  was 
established. 

NOTES 

1  An  <F-OPEN  response>  without  a  <  document  type  name>  (but  carrying  the  <  constraint  set  name>  and 
< abstract  syntax  name>  form)  may  cause  the  Initiator  to  issue  an  <F-CLOSE  request>. 

2  If  the  <  document  type  name>  used  requires  DU  syntax  parameters  and  one  of  the  parameters  specifies 
'FloatingPointNumber'  as  a  primitive  data  type,  the  request  may  be  rejected,  in  case  the  optional  type 
'FloatingPointNumber*  is  not  supported  by  the  Responder. 
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10.3    Relationship  between  DUs,  DEs  and  document  types 

"Abstract  Syntax"  is  used  to  refer  to  the  syntactic  information  wliich  is  architecturally  passed  between  the 
Application  and  Presentation  Layers.  The  Abstract  Syntax  defines  Data  Element  (DE)  types  which  are  not 
necessarily  ASN.1  primitive  types.  A  Data  Element  (DE)  is  the  smallest  piece  of  data  whose  identity  is 
necessarily  preserved  by  the  Presentation  Service.  Data  types  may  be  made  up  of  other  data  types.  Data 
Elements  are  not  defined  in  terms  of  other  Data  Elements. 

A  Data  Unit  (DU)  is  a  sequence  of  one  or  more  Data  Elements.  Architecturally,  entire,  single  DEs  are  passed 
into  and  out  of  the  application  process.  In  a  real  implementation,  DUs  may  be  passed. 

To  maintain  DU  boundaries  during  transfer,  file  structuring  information  must  be  passed  (1808571 -FADU 
definition  in  ISO  8571-2,  clause  7.5).  A  Data  Element  is  referred  to  as  a  File-Contents-  Data-Element  in  the 
IS08571 -FADU  definition. 

Document  types  refer  to  aspects  of  local  processing  and  storage.  They  describe: 
structural  relationship  between  DUs, 
structure  of  DUs,  called  DU  syntax,  and 
DE  types  found  in  the  file 

Because  document  types  pertain  to  local  processing  and  storage,  the  DU  syntax  makes  assertions  about 
the  syntax  and  the  size  of  DUs  (records)  in  storage.  Parameters  on  the  document  types  provide  this 
information  about  the  syntax  and  size  of  the  DUs. 


11    F-CANCEL  action 

When  an  F-CANCEL  is  sent  or  received,  the  following  occurs: 
no  more  data  is  sent, 
checkpoint  numbers  are  removed,  and 
state  of  the  file  is  implementation  dependent. 

NOTE  -  When  mapping  F-CANCEL  on  P-RESYNCHRONIZE  (abandon)  it  is  required  that  P-SYNC-MINOR  be 
used  after  F-READ/  F-WRITE  (see  ISO  8571-4  clauses  13,  14). 
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12   Implementation  information  agreements 

The  <  implementation  information  >  parameter  of  <F-INITIAUZE>  FPDU  is  not  required  by  these 
Agreements. 

It  may  be  used  to  pass  user  version  information  as  a  series  of  values,  separated  by  ';' 
The  following  will  indicate  conformance  to  the  Phase  2  Agreements:  NBS-Phase2. 

NOTE  -  The  list  of  possible  values  may  be  enlarged  for  future  FTAM  phases  or  FTAM  profiles  of  other  bodies. 
This  parameter  is  for  information  only;  it  is  not  used  for  negotiation. 

The  establishment  of  an  FTAM  regime  should  not  t>e  rejected  only  because  of  an  unknown  <  implementation 
information  >  value. 


13   Diagnostic  agreements 

The  <diagnostic>  parameter  is  supported;  a  value  in  the  < response >  PDU  is  needed  when  the  < action 
result >  or  < state  result >  is  not  zero.  (The  nature  of  these  agreements  is  to  provide  <diagnostic> 
information  when  any  result  parameter  is  not  'success'.) 

General  catch-all  diagnostic  action  is  discouraged. 

The  < further  details >  subfield  is  supported.  It  will  be  encoded  as  GraphicString,  but  is  restricted  to  ISO  646 
(IRV,  graphic  characters)  and  ISO  8859-1  only. 

Use  of  F-P-ABORT  for  other  than  protocol  errors  and  catastrophic  situations  is  discouraged. 
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When  returning  an  error  status  in  a  file  management  related  diagnostic  (i.e.,  <F-READ-ATTRIBUTE 
response >  or  <F-CHANGE-ATTRIBUTE  response >),  identify  the  erroneous  attribute  by  using  the  first  two 
characters  of  <further  details >  to  hold  a  2-digit  number  (encoded  as  lASString)  from  the 
<F-READ-ATTRIBUTE  request >  attributes  abstract  syntax  definition  (ISO  8571-4,  clause  20.3). 


00 

Filename 

01 

Permitted  Actions 

02 

Contents  Type 

03 

Storage  Account 

04 

Date  and  Time  of  Creation 

05 

Date  and  Time  of  Last  Modification 

06 

Date  and  Time  of  Last  Read  Access 

07 

Date  and  Time  of  Last  Attribute  Modification 

08 

Identity  of  Creator 

09 

Identity  of  Last  Modifier 

10 

Identity  of  Last  Reader 

11 

Identity  of  Last  Attribute  Modifier 

12 

File  Availability 

13 

File  Size 

14 

Future  Filesize 

15 

Access  Control 

16 

Legal  Qualifications 

17 

Private  Use 

The  set  of  file  management  diagnostics,  found  in  ISO  8571-3  annex  A,  must  be  supported. 
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In  the  case  where  a  specific  parameter  can  in  no  way  be  accomnriodated  then  the  request  fails  and  a 
<diagnostic>  indicating  one  such  parameter  should  be  returned  by  the  responder.  In  the  case  where  a 
negotiable  parameter  cannot  be  accommodated  with  exactly  the  value  requested  but  is  negotiated  to  a 
different  value  (as  defined  in  the  standard)  then  the  request  formally  succeeds  but  informative  < diagnostics  > 
indicating  those  parameters  negotiated  should  be  returned. 

In  order  to  provide  for  robust  applications  using  FTAM,  well  defined  and  precise  diagnostics  are  required 
to  be  returned  by  responding  implementations  whenever  an  action  cannot  be  carried  out  precisely  as 
requested  with  respect  to  non-negotiable  parameters.  All  such  applicable  diagnostics  will  be  returned  in 
those  cases.  An  action  is  carried  out  precisely  as  requested  with  respect  to  a  parameter  when  the  value 
of  that  parameter  on  the  <  request  >  FPDU  is  equal  to  the  value  in  effect  during  or  subsequent  to  the  action, 
depending  on  whether  the  action  is  regime  control. 

Diagnostics  exist  to  signal  'parameter  not  supported'  and  Responder  implementations  shall  issue  all 
appropriate  diagnostics.  The  < further  details >  subfield  of  the  <diagnostic>  parameter  shall  specify  the 
parameter  which  is  not  implemented. 


14  Concurrency 

The  <  concurrency  control  >  used  by  default  on  actions  requested  by  an  <F-SELECT  indication  >  or  <F- 
CREATE  indication  >  service  are: 

'shared' for  read  and  read  attribute 

'exclusive'        for  all  other  actions 

The  default  for  actions  not  requested  is  specified  as  'not  required'  as  per  ISO  8571-3. 

NOTE  -  A  local  implennentation  may  choose  to  be  more  restrictive  in  order  to  assure  file  consistency  for 
concurrent  accessors. 

FADU  locking  is  not  required. 
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15  Requested  access 

The  <  requested  access >  parameter  on  <F-SELECT>  or  <F-CREATE>  is  used  to  specify  the  actions  which 
the  Initiator  nnay  perform  during  the  file  selection.  The  value  of  the  < requested  access>  parameter  is 
compared  by  the  Responder  to  the  <  access  control  >  and  <  permitted  actions  >  file  attributes  and 
concurrency  controls  (including  those  requested  by  the  Initiator)  currently  in  place  on  the  file.  If  the  value 
of  the  <  requested  access  >  parameter  is  not  consistent  with  either  <  access  control  > ,  <  permitted  actions  > , 
or  concurrency  controls  in  place,  then  the  <F-SELECT>  or  <F-CREATE>  must  be  rejected. 

<  requested  access >  is  consistent  with  <  access  control  >  If,  for  each  action  requested,  that  action  either 
requires  no  password,  or  the  required  password  has  been  specified  on  the  <F-SELECT  request>  or  <F- 
CREATE  request  >. 

<  requested  access >  is  consistent  with  <  permitted  actions >  if,  for  each  action  requested,  that  action  is 
allowed  by  the  <  permitted  actions  >  file  attribute. 

<  requested  access  >  is  consistent  with  <  concurrency  control  >  requested  on  the  <F-SELECT>  or  <F- 
CREATE>  if,  for  each  action  requested,  that  action  has  not  been  specified  as  'not  required'  or  'no  access' 
in  the  <  concurrency  control  >  parameter. 

<  requested  access  >  is  consistent  with  concurrency  controls  in  place  on  the  file  if  for  each  action  requested 
no  other  accessor  of  the  file  has  set  the  concurrency  control  for  that  action  to  either  'exclusive'  or  'no 
access'. 


1 6  Security 


16.1     Initiator  identity  and  filestore  password 

The  <  initiator  identity>  and  <filestore  password  >  parameters  for  an  implementation  acting  as  an  Initiator 
are  supported.  These  parameters  are  optional  for  an  implementation  acting  as  a  Responder. 

The  syntax  of  < initiator  identity>  and  <filestore  password >  is  system-dependent.  < initiator  identity >  and 
<filestore  password >  will  represent  account  information  on  the  local  system,  which  may  be  different  from 
the  <  account  >  parameter. 


16.2    Access  passwords 

The  < access  passwords >  and  < create  password  >  parameters  for  an  implementation  acting  as  an  Initiator 
are  supported  if  the  Security  Group  of  attributes  is  supported.  These  parameters  for  an  implementation 
acting  as  a  Responder  are  optionally  supported  if  the  Security  Group  is  supported. 
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16.3    Implementation  responsibilities 

It  is  the  responsibility  of  eacfi  local  system  to  provide  security  for  its  own  real  filestore.  Encryption  of 
passwords  will  not  be  done  by  FTAM. 

A  user  of  the  file  service  must  be  l<nown  by  the  Responder.  "Known"  is  defined  by  the  local  Filestore,  and 
is  dependent  on  the  level  of  security  provided  by  the  local  Filestore. 

17   Requirement  for  conformant  implementations 

This  clause  gives  the  criteria  to  be  satisfied  by  every  implementation  of  FTAM  that  conforms  to  these 
Agreements. 
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Conformance  to  these  Agreements  is  stated  in  terms  of  the  different  roles  occupied  by  FTAM 
implementations.  The  interoperability  of  certain  configurations  of  these  roles  motivates  this  approach. 
Interoperable  configurations  of  these  roles  are  given  in  17.1. 

The  only  function  provided  by  every  conformant  implementation  is  the  transfer  of  unstructured  binary  files 
in  their  entirety.  It  must  be  recognized  that  such  simple  transfer,  while  commonly  understood  and  generally 
important,  will  not  support  all  applications  of  FTAM.  Clause  18  defines  Implementation  Profiles  of  FTAM 
services  and  protocol  that  can  provide  other  specific  functions.  Those  other  functions  exploit  the  access 
and  management  capabilities  of  FTAM.  The  unconstrained  service  class  (with  appropriately  chosen  functional 
units)  can  be  used  to  provide  the  functions  of  any  of  the  Implementation  Profiles.  Users  of  FTAM  must 
consider  carefully  what  functions  they  require.  They  must  examine  all  the  Implementation  Profiles  and  select 
according  to  their  needs. 

Implementations  conforming  to  these  Agreements  require  adherence  to  the  General  Agreements  in  clauses 
5  through  16  of  these  Agreements. 

Implementations  conforming  to  these  agreements  shall  implement  the  defect  report  solutions  contained  in: 

ISO  8571-1 /Cor.1: 1990 
ISO  8571 -2/Cor.1 -.1990 
ISO  8571 -3/Cor.1:1 990 
ISO  8571 -4/Cor.1:1 990 

ISO  8571 -3/Cor.2: 1990 
ISO  8571 -4/Cor.2: 1990 

Editor's  Note  -  The  corrigenda  ISO  8571-3/Cor.2  and  ISO  8571-4/Cor.2  is  to  be  published.  Until  it  is 
available,  the  solutions  can  be  found  in  the  documents  ISO/IEC  JTC1  /SC21  N  5234  and  ISO/IEC  JTCI  /SC21 
N  5235. 


17.1     Interoperable  configurations 

Any  implementation  conforming  to  this  specification  must  be  able  to  act  in  at  least  one  of  the  following  role 
combinations: 

1 .  initiator  and  receiver, 

2.  initiator  and  sender, 

3.  responder  and  sender, 

4.  responder  and  receiver. 

Minimal  implementations  of  combination  1  will  interoperate  with  minimal  implementations  of  combination  3. 
Minimal  implementations  of  combination  2  will  interoperate  with  minimal  implementations  of  combination  4. 
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Any  implementations  of  roles  1  and  3  will  be  able  to  interoperate  at  the  intersection  of  their  capabilities 
(which  will  be  at  least  the  minimal  capabilities  described  in  17.3  to  17.8).  Any  implementations  of  roles  2 
and  4  will  be  able  to  interoperate  at  the  intersection  of  their  capabilities  (which  will  be  at  least  the  minimal 
capabilities  described  in  17.3  to  17.8). 

These  role  combinations  and  this  interoperability  are  shown  in  table  5  below. 


Table  5  -  Interoperable  configurations. 


InKiator 

Responder 

sender 

receiver 

sender 

receiver 

Initiator 

sender 

X 

receiver 

X 

Responder 

sender 

X 

receiver 

X 

17.2    Relationship  to  ISO  8571 -The  FTAM  Standard 

Any  implementation  in  conformance  to  ISO  8571  (as  defined  in  ISO  8571-4,  clause  22  (Conformance)),  in 
addition  to  the  implementation  of  the  minimal  protocols  and  roles  enumerated  in  subclauses  17.3  to  17.8, 
is  considered  to  be  in  conformance  with  these  Agreements.  Any  implementation  violating  any  of  the 
conformance  statements  in  ISO  8571-4  is  considered  to  be  in  violation  of  these  Agreements. 


17.3    Requirements  for  document  type  support 

The  document  type  FTAM-3  shall  be  supported  for  purposes  of  transfer  and  storage.  The  details  regarding 
support  for  FTAM-3  in  the  FTAM  dialogue  are  given  in  clause  10. 

Support  of  document  types  other  than  FTAM-3  is  not  required  for  conformant  implementations.  Support 
for  document  types  described  in  these  Agreements  also  entails  support  for: 

the  semantics  given  in  their  description  and  further  qualified  in  clause  10 

the  preferred  transfer  syntax  "Basic  Encoding  of  a  single  ASN.1  type" 
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Every  implementation  of  an  FTAM  Initiator  shall  support: 

the  kernel  protocol  and  its  mandatory  parameters  with  minimum  ranges  [Minimum  required  ranges 
are  specified  in  17.8.], 

the  grouping  protocol  and  the  <threshold>  parameter  with  a  value  of  at  least  2  for  use  in  the  file 
transfer  class, 

at  least  one  of  the  read  or  write  protocols  [Specific  conformance  for  reading  and  writing  is  defined 
in  17.6  and  17.7.], 

and  support  the  applicable  procedures  defined  in  ISO  8571 -4  clauses  8.1  (FTAM  regime  establishment),  8.2 
(FTAM  regime  termination),  8.3  (File  selection),  8.4  (File  deselection),  8.9  (File  open),  8.10  (File  close),  8.11 
(Begin  group),  8.12  (End  group),  and  10  (File  general  actions).  To  support  the  above  protocols  and 
procedures  the  implementation  shall  always  support  the  kernel  functional  unit  and  additionally  shall  be  able 
to: 

request  the  grouping  and  at  least  one  of  the  read  or  write  functional  units, 
request  the  file  transfer  class  with  the  <  service  class  >  parameter, 

request  the  document  type  FTAM-3  using  the  <  document  type  name>  form  of  the  <  contents  type> 
parameter, 

request  the  <FTAM  quality  of  service  >  parameter  with  value  0  and  accept  in  all  cases  the  returned 
value  0,  and 

request  a  <  communication  quality  of  service >  consistent  with  the  transport  definition  in  these 
agreements. 

as  part  of  the  Filestore  initialization  procedures  in  ISO  8571-4  clause  8.1,  FTAM  regime  establishment. 

Initiators  must  be  able  to  operate  under  all  circumstances  if  the  above  minimum  values  are  successfully 
negotiated  and  returned  on  an  <F-INITIALIZE  response >  PDU.  Initiators  must  be  able  to  operate  with  any 
downward  negotiation  of  requested  parameter  values  as  described  in  the  standard. 

Should  the  supporting  services  break  down,  such  that  FTAM  communication  is  impossible,  the  FTAM 
protocol  machine  shall  notify  the  user  with  an  <F-P-ABORT  indication >  and  <diagnostic>  value  with 
identifier  1011,  as  well  as  any  known  <further  details>. 

NOTE  -  Interworking  may  not  be  possible  between  Initiators  not  supporting  attributes  of  the  Storage  Group 
and  Security  Group,  and  Responders  requiring  these  attributes  to  be  used. 
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17.5  Responders 

Every  implementation  of  an  FTAM  Responder  shall  support: 

the  kernel  protocol  and  its  mandatory  parameters  with  minimum  ranges  [Minimum  required  ranges 
are  specified  in  17.8.], 

the  grouping  protocol  and  the  <threshold>  parameter  with  a  value  of  at  least  2  for  use  in  the  file 
transfer  class, 

at  least  one  of  the  read  or  write  protocols  [Specific  conformance  for  reading  and  writing  is  defined 
in  17.6  and  17.7], 

and  support  the  applicable  procedures,  defined  in  ISO  8571 -4  clauses  9.1  (FTAM  regime  establishment),  9.2 
(FTAM  regime  termination),  9.3  (File  selection),  9.4  (File  deselection),  9.9  (File  open),  9.10  (File  close),  9.11 
(Begin  group),  9.12  (End  group),  and  10  (File  general  actions).  To  support  the  above  protocols  and 
procedures  the  implementation  shall  always  support  the  kernel  functional  unit  and  additionally  shall  be  able 
to: 

accept  requests  for  the  grouping  and  at  least  one  of  the  read  or  write  functional  units, 

accept  requests  for  the  file  transfer  class  with  the  <  service  class  >  parameter, 

accept  the  document  type  FTAM-3  using  the  <  document  type  name>  form  of  the  <  contents  type> 
parameter, 

accept  requests  for  an  <  FTAM  quality  of  service  >  parameter  with  any  value  but  may  respond  with 
the  value  0,  and 

accept  requests  for  a  <  communication  quality  of  service >  consistent  with  the  transport  definition 
in  these  agreements 

as  part  of  the  filestore  initialization  procedures  in  ISO  8571-4  clause  9.1,  FTAM  regime  establishment. 

Responders  must  be  able  to  operate  under  all  circumstances  if  the  above  minimum  values  are  requested 
on  an  <F-INITIAUZE  request>  PDU.  Responders  must  not  negotiate  upward  in  the  sense  described  in  the 
standard. 

Responders  must  complete  each  action  requested  and  supported  in  a  manner  consistent  with  its  description 
in  ISO  8571  -2  clauses  1 0  (Actions  on  complete  files)  and  1 1  (Actions  for  file  access),  and  must  interpret  each 
supported  attribute  in  a  manner  consistent  with  its  definition  in  ISO  8571-2  clause  12  (File  attributes). 

Under  circumstances  where  actions  cannot  be  carried  out  either  as  requested  or  consistently  with  ISO  8571  - 
2  clause  10  (Actions  on  complete  files)  and  12  (Actions  for  file  access),  the  Responder  must  return  at  least 
one  diagnostic  indicating: 

■rf  the  failure  was  due  to  either  a  protocol  or  Filestore  failure,  and  then: 

1)  precisely  which  action  failed, 
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2)  at  least  one  of  the  parameters  that  could  not  be  accommodated  with  the  diagnostic 
type  indicating  at  least  the  degree  of  failure,  as  given  by  the  action  and  state  result 
parameter,  or 

that  the  failure  was  due  to  unforeseen  system  shutdown. 

Should  the  supporting  sen/ices  break  down,  such  that  FTAM  communication  is  impossible,  the  FTAM 
protocol  machine  shall  notify  the  user  with  an  <F-P-ABORT  indication >  and  <diagnostic>  with  identifier 
1011,  as  well  as  inform  the  user  of  any  known  <further  details>. 


17.6  Senders 

Every  implementation  of  an  FTAM  sender  shall  support  the  read  functional  unit  as  Responder  or  the  write 
functional  unit  as  Initiator,  and  support  the  applicable  procedures  defined  in  ISO  8571-4  clauses  11  (State 
of  the  bulk  data  transfer  activity),  12  (Bulk  data  transfer  protocol  data  units),  15  (Bulk  data  transfer  sending 
entity  actions),  17.1  (Discarding),  and  17.2  (Cancel). 

To  support  those  procedures  the  implementation  shall  be  able  to  send  files  of  the  document  type  FTAM-3 
and  shall  be  able  to  send  them  as  user  data  in  PPDUs  in  blocks  of  up  to  7168  octets. 


17.6.1      Initiator  Senders 

Every  implementation  of  an  FTAM  sender  which  is  also  an  FTAM  Initiator  shall  support: 
the  write  functional  unit  and  protocol,  and 

for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 


and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clause  13  (Bulk  data  transfer  initiating  entity 
actions). 

17.6.2      Responder  Senders 

Every  implementation  of  an  FTAM  sender  which  is  also  an  FTAM  Responder  shall  support: 
the  read  functional  unit  and  protocol,  and 

for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 


FADU  operation 


replace 


FADU  identity  first 


1)  FADU  identity 


first 


2)  Access  context 


UA 
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and  support  the  applicable  procedures,  defined  in  ISO  8571  -4  clause  1 4  (Bulk  data  transfer  responding  entity 
actions). 

1 7.7  Receivers 

Every  innplementation  of  an  FTAM  receiver  shall  support  the  read  functional  unit  as  Initiator  or  the  write 
functional  unit  as  Responder,  and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clauses  11 
(State  of  the  bulk  data  transfer  activity),  12  (Bulk  data  transfer  protocol  data  units),  16  (Bulk  data  transfer 
receiving  entity  actions),  17.1  (Discarding),  and  17.2  (Cancel). 

To  support  those  procedures  the  implementation  shall  be  able  to  receive  files  of  the  document  type  FTAM-3 
and  shall  be  able  to  receive  them  as  user  data  in  PPDUs  in  blocks  of  at  least  7168  octets. 

17.7.1  Initiator  Receivers 

Every  implementation  of  an  FTAM  receiver  which  is  also  an  FTAM  Initiator  shall  support: 
the  read  functional  unit  and  protocol,  and 

for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 

1)  FADU  identity  first 

2)  Access  context  UA 

and  support  the  applicable  procedures,  defined  in  ISO  8571-4  clause  13  (Bulk  data  transfer  initiating  entity 
actions). 

17.7.2  Responder  Receivers 

Every  implementation  of  an  FTAM  receiver  which  is  also  an  FTAM  Responder  shall  support: 
the  write  functional  unit  and  protocol,  and 

for  the  document  type  FTAM-3  the  following  bulk  data  transfer  specification  parameters: 

1)  FADU  operation  replace 

2)  FADU  identity  first 

and  support  the  applicable  procedures,  defined  in  ISO  8571  -4  clause  1 4  (Bulk  data  transfer  responding  entity 

actions). 


26 


Part  9  -  FTAM  Phase  2 


December  1991  (Stable) 


17.8    Minimum  ranges 

Any  implementation  of  any  conformant  FTAM  configuration  shall  be  able  to  receive  and  meaningfully  process 
all  mandatory  parameters  for  ail  functional  units  supported  as  well  as  the  <diagnostic>  parameter  within 
at  least  the  minimum  ranges  of  values  given  in  table  6.  A  conforming  implementation  may  support  a  wider 
range  of  values  for  any  parameter. 


Table  6  -  Required  minimal  parameter  support 


Parameter 

Minimum  Range 

general 

diagnostic 

Values  as  specified  in  ISO  8571-3  annex  A  (Diagnostic 
parameter  values)  tables  44,  45  and  46  which 
correspond  directly  to  mandatory  parameters. 

action  result 

All  values 

state  result 

All  values 

F-INITIALIZE 

functional  units^ 

'read'  (for  initiator/receivers  and  responder/senders) 

and  'grouping' 

or 

'write'  (for  initiator/senders  and  responder/receivers) 
anu  grouping 

presentation  context 
management^ 

'False' 

all  others 

As  specified  in  1 7.4  and  1 7.5  above 

F-SELECT 

attributes 

Only  <  filename  >  is  used  with  a  minimum  supportable 
length  of  8  characters.  Any  other  attribute  supported 
for  other  services  must  have  minimum  supported 
lengths  as  in  ISO  8571-2  clause  15  (Minimum  attribute 
ranges),  table  2. 

requested  access 

'read'  for  initiator/receivers 
'read'  for  responder/senders 
'replace'  for  initiator/senders 
'replace'  for  responder/receivers 

F-CREATE 

override 

For  Responders,  the  values  'create-failure',  'select-old- 
file'  and  'delete-and-create-with-new-attributes'  are 
supported.  The  value  'delete-and-create-with-old- 
attributes'  is  optionally  supported.  All  values  are 
optional  for  Initiators. 
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Table  6  -  Required  minimal  parameter  support,  (concluded) 


Parameter 

Minimum  Range 

F-OPEN 

processing  mode 

'read'  for  initiator/receivers 
'read'  for  responder/senders 
'replace'  for  initiator/senders 
'replace'  for  responder/receivers 

contents  type 

'FTAM-3' 

F-READ 

FADU  identity 

'first' 

access  context 

'UA' 

F-WRITE 

FADU  operation 

'read'  for  initiator/receivers 
'read'  for  responder/senders 
'replace'  for  initiator/senders 
'replace'  for  responder/receivers 

FADU  identity 

'first' 

F-BEGIN-GROUP 

threshold^ 

For  file  transfer  (a  minimal  required  function)  2 

For  any  other  supported  parameters,  minimum  ranges  are  taken  from  tlie  minimum  ranges  for  the  attribute 
corresponding  to  each  as  in  ISO  8571-2  table  4. 

NOTES 

1  The  parameters,  functional  units,  and  presentation  context  management  are  not  ordered,  so  "minimum 
value"  cannot  be  formally  defined.  The  above  values  are  those  required  for  conformance  to  these  Agreements 
but  no  value  conformant  to  ISO  8571  for  use  in  other  applications  is  regarded  to  be  in  violation  of  these 
Agreements. 

2  Other  functional  units  (and  service  classes)  for  defined  implementations  may  also  be  valid  provided  that  they 
are  implemented  in  accordance  with  these  Agreements,  specifically  subclause  1 7.8. 

3  Every  implementation  must  support  the  <  threshold  >  value  2  to  provide  the  basic  required  function  of  file 
transfer;  any  other  value  in  other  applications  is  acceptable. 


28 


Part  9  -  FTAM  Phase  2 


December  1991  (Stable) 


17.9  Range  of  values  for  INTEGER  type  parameters 

The  general  range  for  parameters  of  type  INTEGER  to  the  FTAM  PCI  is  as  specified  in  the  UNIVERSAL 
ASN.1  ENCODING  RULES  clause  of  the  Upper  Layers  part. 

The  parameters 

FTAM  Attributes 

filesize 

future-filesize 
FADU-ldentity 

fadu-number 

may  be  encoded  so  that  the  length  of  its  contents  octets  is  no  more  than  eight  octets. 
In  the  case  of  receiving  more  than  4  contents  octets,  the  receiver  may  reject  the  corresponding  FTAM  PDU. 
NOTE  -  To  guarantee  interworking,  encoding  should  be  restricted  to  the  range  -2^^  to  2^^-1. 

17.10  Use  of  lower  layer  services 

Support  for  the  Presentation  Context  Management  functional  unit  is  not  required. 

Implementations  will  support  the  Session,  Presentation,  and  ACSE  requirements  as  stated  in  part  5  of  this 
document. 

NOTE  -  Implementation  of  the  Session  Resychronize  and  the  Minor  Synchronize  functional  units  is  highly 
recommended,  since  the  F-CANCEL  service  may  be  less  effective  v^^hen  mapped  to  S-DATA. 
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18   Implementation  Profiles 

This  clause  defines  Implementation  Profiles  for  the  specific  functions  of: 

File  Transfer  , 

File  Access 

File  Management 
Those  definitions  are  expressed  in  terms  of: 

Document  Types 

Attributes 

Service  Classes  (both  sen/ice  elements  and  their  parameters). 

This  by  no  means  defines  all  possible  Implementation  Profiles.  The  following  Implementation  Profiles  are 
defined: 

T1  :  Simple  File  Transfer 
T2  :  Positional  File  Transfer 
T3  :  Full  File  Transfer 
A1  :  Simple  File  Access 
A2  :  Full  File  Access 
M1  :  Management. 

Implementation  Agreements  have  been  reached  for  the  following  service  classes. 
File  Transfer 
File  Access 
File  Management 
Unconstrained  ' 
File  Transfer  and  Management 

NOTE  -  Any  given  implementation  may  support  more  than  one  service  class. 
Support  of  an  Implementation  Profile  requires  adherence  to: 
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corresponding  definition  in  8571-3  clause  8  and  any  related  procedures  in  8571-4  clause  8-17, 
requirements  given  in  clauses  5-18  of  these  Agreements,  and 
requirements  for  parameter  and  attribute  support  as  defined  in  1 7.8. 

18.1  General  requirements  for  the  defined  Implementation  Profiles 

Implementations  will  be  able  to  act  either  as  Initiator  or  Responder  or  both. 

Implementations  must  support  diagnostics  as  described  in  clause  13  of  these  Agreements. 

Implementations  that  support  the  file  access  sen/ice  class  will  support  access  to  sequential  files.  Support 
of  sequential  files  entails  hierarchy  of  depth  and  arc  length  equal  to  1 .  Other  hierarchy  depth  and  arc 
lengths  are  not  precluded  by  these  agreements. 

18.2  (deleted) 

18.3  Document  type  requirements  for  the  defined  Implementation 
Profiles 

Implementations  conformant  to  Implementation  Profiles  defined  in  table  7  will  support  the  following 
document  types  with  the  caveats  and  procedures  given. 

FTAM-1 

FTAM-2 

FTAM-3 

NBS-6 

NBS-7 

NBS-8 

NBS-9 

NOTES 

1  Support  of  this  document  type  entails  the  naming  of  FADUs  by  their  position  in  preorder  traversal. 

2  Caveat:  Other  methods  of  naming  FADUs  depend  on  the  system,  application,  and  specific  file,  and  as  such 
are  not  described  here. 
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3  Those  document  types  are  defined  in  annex  A  and  clause  10  of  these  Agreements,  and  in  ISO  8571-2. 

Support  for  any  document  type  requires  the  ability  to  transfer  and  store  the  abstract  syntax  given  in  its 
definition.  These  Agreements  do  not  specify  techniques  or  formats  for  storage. 

NOTE  -  Specific  abstract  syntaxes  for  the  parameterized  document  types  NBS-6,7,8  are  not  specified  in  these 
Agreements. 

Any  document  type  supported  must  be  identifiable  by  its  document  type  name  as  given  in  ISO  8571-2  and 
in  annex  A  of  these  Agreements  and,  where  defined,  the  parameterization  scheme  given  in  clause  10  of 
these  Agreements. 

For  conformance  to  NBS-9  a  Responder  is  only  required  to  return  the  < filename  >  attribute,  subject  to  local 
security  and  access  control.  All  other  requested  attributes  need  not  be  returned. 

Systems  supporting  the  NBS-9  document  type  shall  make  available  an  NBS-9  document  called  'DIRLIS'. 
This  document  can  be  used  to  obtain  a  listing  of  files  and  their  associated  attributes  from  a  remote  Filestore. 

Creation  and  deletion  of  NBS-9  files  are  outside  the  scope  of  these  Agreements. 

File  security  issues  related  to  NBS-9  are  subject  to  the  security  agreements  outlined  in  clause  16. 


18.4    Parameters  for  the  defined  Implementation  Profiles 

Implementations  will  support  the  <contents  type  list>  parameter  on  the  <F-INITIALIZE>  service  element. 
The  initiating  service  must  supply  a  value  for  this  parameter. 

Implementations  will  support  the  <diagnostic>  parameter  as  stated  in  clause  13  of  these  Agreements. 

The  < initiator  identity>  parameter  is  supported.  Use  must  be  consistent  with  clause  16  of  these 
Agreements. 

Implementations  are  not  precluded  from  using  other  parameters  for  security  and/or  accounting.  Responders 
must  state  the  syntax  and  the  semantics  applying  to  <  account  >  and  <  charging  >  parameters.  The 
Responder's  minimum  implementation  is  to  accept  but  ignore  the  <  account  >. 


1 8.5    Parameter  ranges  for  the  defined  Implementation  Profiles 

Parameter  ranges  for  Implementations  Profiles  are  as  stated  for  primitive  data  types  in  clause  10  of  these 
Agreements. 


I V'.- 
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18.6    File  attribute  support  for  Implementations 

Implementations  of  the  Implementation  Profiles  will  support  file  attributes  or  attribute  groups  in  the  following 
ways: 

a)  mandatory  -  This  feature  is  mandatory  in  the  ISO  8571-2  standard  and  shall  therefore  be 
implemented  by  all  implementations  claiming  conformance  to  these  Agreements; 

b)  supported  -  This  feature  shall  be  implemented  by  all  implementations  claiming  conformance  to 
these  Agreements  (for  attributes,  this  implies  that  at  least  the  minimum  range  of  attribute  values,  as 
defined  in  ISO  8571-2  clause  15,  shall  be  supported).  Conformant  implementations  shall  also  be 
able  to  intenA/ork  with  other  implementations  that  do  not  support  this  feature  by  negotiating  out  the 
corresponding  features; 

c)  optionally  supported  -  Implementations  claiming  conformance  to  these  Agreements  may  or  may 
not  implement  this  feature  (for  attributes,  this  implies  that  at  least  either  the  minimum  range  of 
attribute  values,  as  defined  in  ISO  8571-2  clause  15,  shall  be  supported  or  that  the  'no  value 
available'  result  shall  be  supplied).  If  an  attribute  group  with  a  support  level  of  'optionally  supported' 
is  chosen  to  be  supported,  then  all  the  attributes  of  this  group  that  are  classified  as  'mandatory'  or 
'supported'  shall  be  supported; 

d)  not  supported  -  This  feature  is  outside  the  scope  of  these  Agreements. 
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Kernel  Group 

Filename 
Permitted  Actions 
Contents  Type 

Storage  Group 

Storage  Account 

Date  and  Time  of  Creation 

Date  and  Time  of  Last  Modification 

Date  and  Time  of  Last  Read  Access 

Date  and  Time  of  Last  Attribute  Modification 

Identity  of  Creator 

Identity  of  Last  Modifier 

Identity  of  Last  Reader 

Identity  of  Last  Attribute  Modifier 

File  Availability 

Filesize 

Future  Filesize 

Security  Group 

Access  Control 
Legal  Qualifications 

Private  Group 


mandatory 
mandatory 
mandatory 
mandatory 

optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
optionally  supported 
supported 
supported 

optionally  supported 

optionally  supported 
supported 

optionally  supported 
not  supported 
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Table  7  -  Implementation  profile  support  requirements 


Service  Classes    (see  note  8) 

Functional  Units 

T 

M 

 :  ,  .  

A 

TM 

Uncon- 
strained 

Kernel 

T1,  T2,  T3 

M1 

A1,  A2 

 ..  

Read   (see  note  3) 

_  

T1,  T2,  T3 

A1,  A2 

Write   (see  note  3) 

11,  T2,  T3 

A1,  A2 

Limited  File  Management 

see  note  6 

M1 

see  note  6 

Enhanced  File 

M1 

Management 

Grouping 

T1,  T2,  T3 

M1 

see 

see 

File  Access 

A1,  A2 

note  4 

note  5 

Document  Types 

FTAM-1 

T1,  12,  13 

[M1] 

A1,  A2 

FTAM-2 

12,  13 

[M1] 

A1,  A2 

FTAM-3 

T1,  T2,  T3 

[M1] 

A1,  A2 

NBS-6 

[T2],  T3 

[M1] 

[A1],  A2 

NBS-7 

F2].  T3 

[M1] 

[A1],  A2 

NBS-8 

T3 

[M1] 

A2 

NBS-9 

[T1],  [T2],  [T3] 

[M1] 

NOTES 

to  18.3  and  table  7 

1  The  Management  Implementation  Profile  is  only  to  be  implemented  in  conjunction  with  one  of  the  Transfer 
or  Access  Profiles. 

2  Profile  T2  is  subset  of  T3.  A1  and  T1  are  subsets  of  A2  and  T2,  respectively. 

3  Profiles  T1,  T2,  and  T3  require  the  support  of  read  and/or  write  functional  units. 

4  Support  of  the  <File  Transfer  and  Management>  sen/ice  class  is  optional.  The  rules  for  including  it  in  a 
request  and  for  the  response  to  it  are  as  given  in  ISO  8571-3,  clause  10.1.  Any  implementation  including  TM 
in  the  request  must  be  prepared  for  the  possibility  that  it  might  be  removed  from  the  response. 

5  The  support  of  the  <  Unconstrained >  service  class  is  outside  the  scope  of  these  Implementation  Profiles. 

6  Limited  File  Management  is  not  required  for  the  T-  and  A-  Implementation  Profiles,  but  very  often  it  will  be 
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a  user  request  to  have  limited  file  management  functionality  available  together  w/ith  file  transfer  and  file  access 
functions.  So  Limited  File  Management  may  be  added  as  an  option  to  the  T-  and  A-  Implementation  Profiles. 

7  [  ]  in  table  7  specifies  that  the  document  type  is  optional  for  the  respective  Implementation  Profile.  For  M1 
the  support  level  depends  on  the  T-  or  A-  Implementation  Profile,  in  conjunction  with  which  M1  is  implemented. 

8  The  Implementation  Profiles  specify  functionality  which  includes  the  requirements  for  conformant 
implementations  as  specified  in  clause  1 7.  This  is  a  general  basic  requirement  and  is  not  also  reflected  in  table 
7. 

19   PROVISION  OF  SPECIFIC  FUNCTION 

19.1  Implementation  Profile  T1 :  Simple  File  Transfer 

Inriplementation  Profile  T1  provides  the  function  of  transferring  entire  files  at  the  external  file  service  level  for 
files  with  an  unstructured  constraint  set.  This  includes  support  of  the  document  types: 

FTAM-1  "ISO  FTAM  unstructured  text" 

ij  FTAM-3  "ISO  FTAM  unstructured  binary" 

NBS-9  "NBS-9  file  directory  file"  (optional) 
This  Implementation  Profile  supports  file  transfer  and  not  file  access,  that  is,  the  ability  to 
:]  read  a  complete  file,  and/or 

write  (replace,  extend)  to  a  file. 

1...    '  ■ 

19.2  Implementation  Profile  T2:  Positional  File  Transfer 

Implementation  Profile  T2  provides  the  function  of  transferring  files  at  the  external  file  service  level  for  files 
with  an  unstructured  or  flat  constraint  set.  This  Includes  support  of  the  document  types: 

FTAM-1  "ISO  FTAM  unstructured  text" 

FTAM-2  "ISO  FTAM  sequential  text" 

FTAM-3  "ISO  FTAM  unstructured  binary" 

NBS-S  "NBS-6  FTAM  sequential  file"  (optional) 

NBS-7  "NBS-7  FTAM  random  access  file"  (optional) 

'  NBS-9  "NBS-9  file  directory  file"  (optional) 
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This  Implementation  Profile  supports  file  transfer  and  not  file  access,  that  is,  the  ability  to 
read  a  complete  file  or  a  single  FADU  which  is  identified  by  position,  and /or 
write  (replace,  extend,  insert  depending  on  constraint  set  and  document  type)  to  a  file  or  an  FADU. 

This  Implementation  Profile  is  upwardly  compatible  to  T1  for  the  transfer  of  unstructured  files. 

19.3  Implementation  Profile  T3:  Full  File  Transfer 

Implementation  Profile  T3  provides  the  function  of  transferring  files  at  the  external  file  service  level  for  files 
with  an  unstructured,  flat  or  general  hierarchical  constraint  set.  This  includes  support  of  the  document 
types: 

RAM-1  "ISO  FTAM  unstructured  text" 

FTAM-2  "ISO  FTAM  sequential  text" 

FTAM-3  "ISO  FTAM  unstructured  binary" 

NBS-6  "NBS-6  FTAM  sequential  file" 

NBS-7  "NBS-7  FTAM  random  access  file" 

NBS-8  "NBS-8  FTAM  indexed  file" 

NBS-9  "NBS-9  file  directory  file"  (optional) 
This  Implementation  Profile  supports  file  transfer  and  not  file  access,  that  is,  the  ability  to 

read  a  complete  file  or  a  single  FADU  which  is  identified  by  key  or  by  position,  and/or 

write  (replace,  extend,  insert  depending  on  constraint  set  and  document  type)  to  a  file  or  an  FADU. 
This  Implementation  Profile  is  upwardly  compatible  to  T1  for  the  transfer  of  unstructured  files. 

19.4  Implementation  Profile  A1:  Simple  File  Access 

Implementation  Profile  A1  provides  the  function  of  transfer  of  and  access  to  files  with  unstructured  or  flat 
constraint  sets  at  the  external  file  service  level.  This  includes  support  of  the  document  types: 

FTAM-1  "ISO  RAM  unstructured  text" 

FTAM-2  "ISO  FTAM  sequential  text" 

FTAM-3  "ISO  FTAM  unstructured  binary" 
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NBS-6  "NBS-6  FTAM  sequential  file"  (optional) 
NBS-7  "NBS-7  FTAM  random  access  file"  (optional) 
This  Implementation  Profile  supports  file  transfer  and  file  access,  that  is  the  ability  to 
read  a  complete  file  or  FADUs  which  are  identified  by  position, 

write  (replace,  extend,  insert  depending  on  constraint  set  and  document  type)  to  a  file  or  an  FADU, 
locate  and  erase  within  files. 

19.5  Implementation  Profile  A2:  Full  File  Access 

Implementation  Profile  A2  provides  the  function  of  transfer  of  and  access  to  files  with  unstructured  or  flat 
constraint  sets  at  the  external  file  service  level.  This  includes  support  of  the  document  types: 

FTAM-1  "ISO  RAM  unstructured  text" 

FTAM-2  "ISO  FTAM  sequential  text" 

FTAM-3  "ISO  FTAM  unstructured  binary" 

NBS-6  "NBS-6  FTAM  sequential  file" 

NBS-7  "NBS-7  FTAM  random  access  file" 

NBS-8  "NBS-8  FTAM  indexed  file" 

This  Implementation  Profile  supports  file  transfer  and  file  access,  that  is,  the  ability  to 

read  from  a  complete  file,  or  from  a  series  of  FADUs  which  are  identified  by  key  or  by  position, 

write  (replace,  extend,  insert  depending  on  constraint  set  and  document  type)  to  a  file  or  an  FADU, 

locate  and  erase  within  files. 

19.6  Implementation  Profile  Ml:  Management 

Implementation  Profile  M1  provides  the  function  for  an  Initiator  to  manage  the  files  within  the  Virtual  Filestore, 
to  which  access  is  provided  by  the  Responder.  Management  includes  the  services  of: 

creating  a  file 

deleting  a  file 

reading  attributes  of  a  file 
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changing  attributes  of  a  file. 


20  Harmonization 

The  Implementation  Profiles  for  File  Transfer,  File  Access  and  Management  correspond  to  the  Profiles  of 
SPAG  (Standards  Promotion  and  Application  Group)  in  Europe,  so  that  interworking  will  be  possible.  Those 
Profiles  are  described  in  the  'Guide  to  the  Use  of  Standards'  (GUS);  they  are  the  basis  for  the  Functional 
Standards  as  defined  by  CEN/CENELEC  (Comite  Europeenne  de  Normalization). 

Table  8  -  Implementation  profiles  (OIW)  and  profiles  (SPAG/CEN-CLC) 


Implementation  Profile 

SPAG  /  CEN-CENELEC 

T1 

A/111 

T2 

A/112 

T3 

A/113 

A1 

A/122 

A2 

A/123 

Ml 

A/13 
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Annex  A  (normative) 
FTAM  Document  Types 

Editor's  Note  -  The  objects  defined  in  A.5  through  A.8,  B.2,  C.3  and  C.4  will  be  removed  from  this  document 
after  ISO/IEC  ISP  10607-2  and  ISO/IEC  ISP  10607-2/Amd.1  are  published.  During  the  period  between 
publishing  the  ISP  and  removal  of  the  definitions  from  this  document,  the  definitions  in  the  ISP  will  take 
precedence  over  this  document.  When  the  object  definitions  are  removed,  clauses  A.1  through  A.4,  B.1 ,  C.1 
and  C.2  will  be  changed  to  point  to  the  ISP. 

The  objects  defined  in  A.5  through  A.8,  B.2,  C.3  and  C.4  will  be  removed  from  this  document  after  ISO/IEC 
ISP  10607-2  and  ISO/IEC  ISP  10607-2/Amd.1  are  published.  During  the  period  betweem  publishing  the  ISP 
and  removal  of  the  definitions  from  this  document,  the  definitions  in  the  ISP  will  take  preceedence  over  this 
document.  When  the  object  definitions  are  removed,  clauses  A.I  through  A.4,  B.I,  C.I  and  C.2  will  be 
changed  to  point  to  the  ISP. 

A.1      NBS-6  Sequential  file  document  type 


This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  document-type(5)  sequential (6)} 

was  withdrawn  on  March  16,  1990.  It  was  replaced  with  the  object  NBS-6  Sequential  file  document  type 
with  the  Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5)  sequential (6)} 
defined  in  part  9,  A.5. 


A.2      NBS-7  Random  access  file 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  document-type(5)  random-file(7)} 

was  withdrawn  on  March  16,  1990.  It  was  replaced  with  the  object  NBS-7  Random  access  file  document 
type  with  the  Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5)  random-access(7)} 
defined  in  part  9,  A.6. 
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A.3      NBS-8  Indexed  sequential  file 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(1 )  document-type(5)  indexed-file(8)} 

was  withdrawn  on  March  16, 1990.  it  was  replaced  with  the  object  NBS-8  Indexed  sequential  file  document 
type  with  the  Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5)  indexed-file(8)} 
defined  in  part  9,  A.7. 

A.4      NBS-9  File  directory  file 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(1 )  document-type(5)  file  directory(9)} 

was  withdrawn  on  March  16,  1990.  It  was  replaced  with  the  object  NBS-9  File  directory  file  document  type 
with  the  Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5)  file-directory(9)} 
defined  in  part  9,  A.8. 


A, 


NBS-6  Sequential  file  document  type 


A.5.1 


Entry  Number:  NBS-6 


A.5.2 


Information  objects 
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Table  9  -  Information  objects  in  NBS-6 


HrkciimAnt  tvDA  narriA 

UVvUIIIOIIi    IVf'v  llCilllV 

•fi^o  identified-oroanijation  oiwM4\  ftam<;in^S^  dnrumfint-tvnfi^R^ 

^         luvi  III  1  i^u  yji  um  ii^ciii^i  1  x/i  vvi  1^1  1  icxt  1  loiu  I  o  J  vi^v^u  1 1  l^l  illykv^ioi 

sequential(6)} 

"NBS-6  FTAM  sequential  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

{\so  identified-organization  oiw(14) 
ftamsig(5)  abstract-syntax(2)  nbs-as1(1)} 
"NBS  abstract  syntax  AS1" 

b)  name  for  asname2 

{iso  standard  8571  abstract-syntax(2)  ftam-fadu(2)} 
"FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  Encoding  of  a  single  ASN.1  type" 

parameter  syntax: 

PARAMETERS  ::=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl,  Parameter2} 
ParameterO  ::  =  [0]  INTEGER  {univer-time  (23), 

gen-time  (24), 

boolean  (1), 

null  (5)  } 

Parameterl        [1]  SEQUENCE  { 

universal-class-number-1  INTEGER  {  int  (2), 

bit  (3), 
ia5  (22), 
graphic  (25), 
general  (27), 
octet  (4)}, 

string-length  INTEGER  } 
Parameter2  ::=  [2]  SEQUENCE  { 

private-class-number  INTEGER  {float  (0)}, 
length-1  INTEGER, 
length-2     INTEGER  } 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4)  sequential-flat(2)} 
"FTAM  sequential  flat  constraint  set" 

file  contents: 

Datatypel  ::=  PrimType  -  NBS-AS1 

Datatype2  ::=  Node-Descriptor-Data-Element 
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A.5.3 


Scope  and  field  of  application 


The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  by  FTAIVI. 


NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


A.5.4 


References 


ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 
Management 

A.5.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


A. 5.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 

A.5.7      iDocurTient  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units.  Each  FADU  contains  precisely  zero  or 
one  data  unit  which  consists  of  zero,  one  or  more  data  elements.  The  order  of  each  of  these  elements  is 
significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  sequential  flat  constraint  set  (see  table  9)  These  definitions  appear  in  ISO  8571-2.  As  additional 
constraints  FADU  identity  will  be  limited  to  "begin,"  "end,"  "first"  and  "next". 

For  a  specific  file  the  number  of  data  elements  in  a  data  unit  is  given  by  the  parameters.  Each  data  element 
is  a  data  type  from  the  set  of  primitive  data  types  defined  in  the  annex  0.3  of  this  document.  Each  data 
unit  contains  the  same  data  element  types  in  the  same  order  as  all  other  data  units.  These  types  are 
determined  by  the  parameters  0  through  2. 

For  datatype  1,  the  string  length  field  of  Parameterl  specifies  the  length  of  the  value  in  octets  for  the 
INTEGER,  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the  string-length 
indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including  any  escape 
sequences  or  overhead  from  the  character  encoding. 

For  floating  point  numbers,  finite  form,  length-1  and  length-2  specify  the  length  in  bits  of  mantissa  and 
exponent,  respectively.  The  iength-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating  point 
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numbers. 


A.5.8       Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the  ASN.1 
module  IS08571-FADU  in  ISO  8571,  in  which  each  of  the  file  access  data  units  has  the  abstract  syntactic 
structure  of  NBS-AS1  as  defined  by  the  parameters. 


A.5.9       Definition  of  transfer 

A.5.9.1         Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  9,  where  the  PrimType  in  the  datatype  is  given  by  the  NBS-AS1 
definition;  or 

b)  Datatype2  defined  in  table  9,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  IS08571-FADU. 

A.5.9.2        Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  in  the  same  (but  any  )  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel"  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2." 

NOTES 

1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used,  where 
the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  boundaries  between 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document  with 
any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 
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A.5.9.3 


Sequence  of  presentation  data  values 


The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of  types 
a)  and  b)  is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the  hierarchical 
structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO  8571-2. 


A.5.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
in  table  9  for  all  presentation  data  values  transferred.  Implementation  may  optionally  support  other  named 
transfer  syntaxes. 


A.5.11      ASE  Specific  specifications  for  FTAM 


A.5.11.1        Structural  Simplification 

This  structural  simplification  loses  information. 

The  document  type  NBS-6  may  be  simplified  to  the  document  type  FTAM-3  (allowed  only  when  reading  the 
file).  The  octet  representation  of  the  transferred  data  is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 


A.5.11. 2      Access  context  selection 

A  document  of  type  NBS-6  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  sequential 
flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived  from  the 
structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


A.5.1 1 .3       The  INSERT  operation 

When  the  <INSERT>  operation  is  applied  at  the  end  of  file,  the  transferred  material  shall  be  the  series  of 
FADUs  which  would  be  generated  by  reading  any  NBS-6  document  with  the  same  parameter  values  in 
access  context  FA. 


A=6 


NBS~7  Randonn  access  file 
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Table  10  -  Information  objects  in  NBS-7 


document  type  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 
random-file(7)} 

"NBS-7  FTAM  random  access  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2) 
nbs-as1(1)} 

"NBS  abstract  syntax  AS1" 

{iso  standard  8571  abstract-syntax(2)  ftam-  fadu(2)} 
"FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  Encoding  of  a  single  ASN.1  type" 

parameter  syntax: 

PARAMETERS  ::=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl,  Parameter2} 
ParameterO  ::=  [0]  INTEGER  {univer-time  (23), 

gen-time  (24), 

boolean  (1), 

null  (5)  } 

Parameterl  ::=  [1]  SEQUENCE  { 

universal-class-number-1  INTEGER  {  int  (2), 
•                                                          bit  (3), 

ia5  (22), 
graphic  (25), 
general  (27), 
octet  (4)}, 

string-length  INTEGER  } 
Parameter2  ::=  [2]  SEQUENCE  { 

private-class-number  INTEGER  {float  (0)}, 
length-1  INTEGER, 
length-2      INTEGER  } 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  identified-organization  oiw(14)  ftamsig(5)  constraint-set(4) 

nbs  ordered-flat(l)} 

"NBS  ordered  fiat  constraint  set" 

file  contents: 

Datatypel  ::  = 

PrimType  - 

-  NBS-AS1 

Datatype2  ::  = 

CHOICE 

{  Node-Descriptor-Data-Element, 
Enter-Subtree-Data-Element  } 
Exit-Subtree-Data-Element  } 

48 


Part  9  -  FTAM  Phase  2  December  1991  (Stable) 

A.6.3      Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  by  FTAM. 
NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


A.6.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 
Management 


A.6.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


A.6.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


A.6.7       Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units.  Each  FADU  contains  precisely  zero  or 
one  data  unit  which  consists  of  zero,  one  or  more  data  elements.  The  order  of  each  of  these  elements  is 
significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  NBS-ordered-flat  constraint  set  (see  table  10).  These  definitions  appear  in  annex  B.2  of  this 
document. 

For  a  specific  file  the  number  of  data  elements  in  a  data  unit  is  given  by  the  parameters.  Each  data  element 
is  a  data  type  from  the  set  of  primitive  data  types  defined  in  the  annex  0.3  of  this  document.  Each  data 
unit  contains  the  same  data  element  types  in  the  same  order  as  all  other  data  units.  These  types  are 
determined  by  the  parameters  0  through  2. 

For  datatype  1,  the  string  length  field  of  Parameterl  specifies  the  length  of  the  value  in  octets  for  the 
INTEGER,  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the  string-length 
indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including  any  escape 
sequences  or  overhead  from  the  character  encoding. 

For  floating  point  numbers,  finite  form,  length-1  and  length-2  specify  the  length  in  bits  of  mantissa  and 
exponent,  respectively.  The  length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating  point 
numbers. 
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A.6.8       Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the  ASN.1 
module  IS08571-FADU  in  ISO  8571,  in  which  each  of  the  file  access  data  units  has  the  abstract  syntactic 
structure  of  NBS-AS1  as  defined  by  the  parameters. 

A.6.9       Definition  of  transfer 

A.6.9.1         Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either: 


a)  Datatypel  defined  in  table  10,  where  the  PrimType  in  the  datatype  is  given  by  the  NBS-ASI 
definition; 

b)  Datatype2  defined  in  table  10,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  IS08571-FADU. 


A.6.g.2        Presentation  data  values 


The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  in  the  same  (but  any  )  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel"; 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2." 


NOTES 


1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used,  where 
the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 


Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  boundaries  between 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document  with 
any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 
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A.6.9.3        Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of  types 
a)  and  b)  is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the  hierarchical 
structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO  8571-2. 


A.6.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
in  table  10  for  all  presentation  data  values  transferred.  Implementation  may  optionally  support  other  named 
transfer  syntaxes. 


A.6.11      ASE  specific  specifications  for  FTAM 


A.6.11.1        Structural  simplification 

This  structural  simplification  loses  information. 

The  document  type  NBS-7  may  be  accessed  as  a  document  type  FTAM-3  (allowed  only  when  reading  the 
file)  by  specifying  document  type  FTAM-3  in  the  <  contents  type>  parameter  in  <F-OPEN  request  >,  and 
limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-7  can  be  accessed  as  a  document  of  type  NBS-6  (allowed  only  when  reading  the 
file)  by  specifying  document  type  NBS-6  with  appropriate  data  type  parameters  in  the  < contents  type> 
parameter  on  the  <F-OPEN  request  >. 


A.6.1 1 .2      Access  context  selection 

A  document  of  type  NBS-7  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  NBS  ordered 
flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived  from  the 
structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


A.6.1 1.3       The  INSERT  operation 

When  the  <INSERT>  operation  is  applied  at  the  end  of  file,  the  transferred  material  shall  be  the  series  of 
FADUs  which  would  be  generated  by  reading  any  NBS-7  document  with  the  same  parameter  values  in 
access  context  FA. 
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A.7      NBS-8  Sndexed  sequential  file 

A.7.1       Entry  Number:  NBS-8 

A.7.2       Information  Objects 


Table  11  -  Information  objects  in  NBS-8 


document  type  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 

indexed-file(8)} 

"NBS-8  FTAM  indexed  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract  syntax(2) 
nbs-as1(1)} 

"NBS  abstract  syntax  AS1" 

{iso  standard  8571  abstract-syntax(2)  ftam-  fadu(2)} 
"FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
'Basic  Encoding  of  a  single  ASN.1  type" 

parameter  syntax: 

PARAMETERS  ::=  SEQUENCE           {DataTypes,  KeyType,  KeyPosition} 

DataTypes  ::=  SEQUENCE  OF  CHOICE  {ParameterO,  Parameterl,  Parameter2} 

KeyType    ::=  CHOICE  {ParameterO,  Parameterl,  Parameter2} 

--  ParameterO,  Parameterl ,  Parameter2,  as  defined  for  the 
-  document  types  NBS-6,  NBS-7 

KeyPosition::  =  INTEGER 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4)  ordered-flat(3)  } 
"FTAM  ordered  flat  constraint  set" 

file  contents: 

Datatypel  ::=  PrimType  -  NBS-AS1 

Datatype2  ::=  CHOICE  {Node-Descriptor-Data-Element, 

Enter-Subtree-Data-Element, 
Exit-Subtree-Data-Eiement  } 

Datatypes  ::=  Primtype  -  as  defined  by  the  NBS  abstract  syntax  AS1 
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A.7.3       Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  using  FTAM. 
NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


A.7.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 
Management 


A.7.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


A.7.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


A.7.7       Document  semantics 

The  document  consists  of  zero,  one  or  more  file  access  data  units.  Each  FADU  contains  precisely  one  data 
unit  which  consists  of  zero,  one  or  more  data  elements.  The  order  of  each  of  these  elements  is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  FTAM  ordered  flat  constraint  set  (see  table  11).  These  definitions  appear  in  ISO  8571-2. 

The  following  additional  requirements  are  specified  for  the  use  of  the  ordered  flat  constraint  set: 

The  FADU  identities  "first,"  "last,"  and  "node  number"  are  not  required  for  conformant 
implementations 

The  identities  "next"  and  "previous"  are  allowed  for  all  FADUs 

Each  data  element  is  a  data  type  from  the  set  of  primitive  data  types  defined  in  annex  C.3  of  this  document. 
Each  data  unit  contains  the  same  data  element  types  in  the  same  order  as  all  other  data  units.  These  types 
and  their  respective  maximum  lengths  are  defined  by  the  <DataTypes>  parameter. 

For  Datatypel  and  Datatypes,  the  string  length  field  of  Parameterl  specifies  the  length  of  the  value  in  octets 
for  the  INTEGER,  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the  string- 
length  indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including  any  escape 
sequences  or  overhead  from  the  character  encoding. 
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exponent,  respectively.  The  length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating  point 
numbers. 

Each  data  unit  in  the  file  has  a  key  associated  with  it,  which  is  the  user-coded  form  of  Node-Name  .  The 
key  of  each  data  unit  is  of  the  same  data  type  as  the  key  of  all  other  data  units  in  the  file  and  is  a  single  data 
element  from  the  set  of  primitive  data  types  defined  in  annex  C.3  . 

The  type  and  length  of  the  key  are  defined  by  the  <KeyType>  parameter. 

The  primitive  data  types  and  minimum  size  ranges  of  each  unit  which  an  implementation  must  accept  as 
a  key  value  are  given  in  the  following  table  12. 

Table  12  -  Datatypes  for  keys 


Key  Type 

Minimum  Range 
(octets) 

Order 

ASN.1  INTEGER 

(1-2) 

increasing  numeric  value 

ASN.1  lASString 

(1-16) 

lexical  order 

ASN.1  GraphicString 

(1-16) 

lexical  order 

ASN.1  GeneralString 

(1-16) 

lexical  order 

ASN.1  OCTET  STRING 

(1-16) 

increasing  value 

ASN.1  GeneralizedTime 

increasing  time  value 

ASN.1  UniversalTime 

increasing  time  value 

NBS-AS1 

FloatingPointNumber 

increasing  numeric  value 

The  position  of  the  key  in  the  data  unit  is  specified  by  the  <  KeyPosition  >  parameter. 
KeyPosition  =  0  implies  the  key  is  not  part  of  the  data 
position  >  0  specifies  the  actual  data  element  in  the  data  unit. 

A.7.8       Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the  ASN.1 
module  1808571 -FADU  in  ISO  8571,  in  which  each  of  the  file  access  data  units  has  the  abstract  syntactic 
structure  of  NBS-AS1  as  defined  by  the  parameters. 
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A.7.9 


Definition  of  transfer 


A.7.9.1 


Datatype  definitions 


The  file  consists  of  data  values  which  are  of 

a)  Datatypel  defined  in  table  11,  where  the  PrimType  in  the  datatype  is  given  by  the  NBS-ASI 
definition;  or 

b)  Datatype2  defined  in  table  11,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  IS08571-FADU;  or 

c)  Datatypes  defined  in  table  1 1 ,  which  specifies  the  user-coded  form  of  the  Node-Name  in  the 
FTAM  FADU  abstract  syntax,  where  user-coded  is  defined  as  EXTERNAL 


A.7.g.2        Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel"  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2";  or 

c)  a  value  of  "Datatypes"  carrying  a  key.  All  values  are  transmitted  in  the  same  (but  any) 
presentation  context  established  to  support  the  abstract  syntax  name  "asnamel." 


1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used,  where 
the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  boundaries  between 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document  with 
any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 


A.7.9.3        Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of  types 
a)  and  b)  is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the  hierarchical 


NOTES 
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structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO  8571-2. 


A.7.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
in  table  1 1  for  all  presentation  data  values  transferred.  Implementation  may  optionally  support  other  named 
transfer  syntaxes. 


A.7.11      ASE  specific  specifications  for  FTAM 


A.7.11.1       Structural  simplification 

This  simplification  loses  information. 

The  document  type  NBS-8  may  be  accessed  as  a  document  type  FTAM-3  (allowed  only  when  reading  the 
file)  by  specifying  document  type  FTAM-3  in  the  <  contents  type>  parameter  in  <F-OPEN  request  >,  and 
limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-8  can  be  accessed  as  a  document  of  type  NBS-6  (allowed  only  when  reading  the 
file)  by  specifying  document  type  NBS-6  with  appropriate  data  type  parameters  in  the  <  contents  type> 
parameter  on  the  <F-OPEN  request  >.  The  traversal  order  of  the  FADUs  must  be  maintained. 

NOTE  -  The  traversal  order  is  as  reading  the  file  as  NBS-8  in  key  order. 


A.7.1 1 .2      Access  context  selection 

A  document  of  type  NBS-8  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  FTAI\/1  ordered 
flat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived  from  the 
structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


A.7.1 1 .3       The  INSERT  operation 

When  the  <INSERT>  operation  is  applied  the  transferred  material  shall  be  the  series  of  FADUs  which  would 
be  generated  by  reading  any  NBS-8  document  with  the  same  parameter  values  in  access  context  FA. 

The  insertion  of  a  new  FADU  after  an  already  existing  FADU  will  be  indicated  via  a  diagnostic  on  TRANSFER- 
END. 
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This  operation  is  excluded  for  use  witli  tfiis  document  type. 

A.8      NBS-9  File  directory  file 
A.8.1       Entry  Number:  NBS-9 
A.8.2       Information  objects 


December  1991  (Stable) 
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Table  13 

-  information  objects  in  NBS-9 

document  type  name 

{iso  identified-organization  oiw/(14)  ftamsig(5)  document-type(5) 

fil6-directory(9)} 

'NBS-9  FTAM  file  directory  file" 

abstract  syntax  names: 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2) 

nbs-as2(2)} 

"NBS  file  directory  entry  abstract  syntax" 

transfer  syntax  names: 

'  

parameter  syntax 

PARAMETERS  ::=  [0]  IMPLICIT  BIT  STRING  { 

-  Kernel  group 

-                   read-filename  (0), 

read-permitted-actions  (1), 

read-contents-type  (2), 

-  Storage  group 

read-storage-account  (3), 

read-date-and-time-of-creation  (4), 

read-date-and-time-of-last-modification  (5), 

read-date-and-time-of-last-read-access  (6), 

read-date-and-time-of-last-attribute-modification(7), 

read-identity-of-creator  (8), 

read-identity-of-last-modifier  (9), 

read-identity-of-last-reader  (10), 

read-identity-of-last-attribute-modifier  (11), 

read-file-availability  (12), 

read-filesize  (13), 

read-future-filesize  (14), 

-  Security  group 

read-access-control  (15), 

read-legal-qualifications  (16), 

~  Private  group 

read-private-use  (17)  } 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 

"FTAM  hierarchical  file  model"  | 

constraint  set 

{iso  standard  8571  constraint-set(4)  unstructured(l)} 

"FTAM  unstructured  constraint  set" 

File  contents: 

Datatypel  ::=  FileDlrectoryEntry 

-As  defined  by  NBS-AS2  in  annex  C, 

~C.4  of  this  document  j 
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A.8.3       Scope  and  field  of  application 

This  document  defines  the  contents  of  a  file  for  transfer  (not  for  storage)  using  FTAM. 


A.8.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer,  Access  and 
Management. 


A.8.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1 


A.8.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management. 


A.8.7       Document  Semantics 

The  document  consists  of  one  file  access  data  unit,  which  consists  only  of  zero,  one  or  more  data  elements 
of  type  <FileDirectoryEntry>  (defined  in  NBS-AS2). 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as  constrained 
by  the  unstructured  constraint  set.  These  definitions  appear  in  ISO  8571-1. 

The  parameter  of  the  document  type  is  used  on  <  F-OPEN  request  >  to  specify  the  desired  attributes  of  each 
of  the  files  on  the  Filestore,  when  reading  the  document. 


A.8.8       Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  series  of  file  directory  entries,  each  of  which  is  defined 
by  the  <FileDirectoryEntry>  definition  in  NBS-AS2. 

Additional  constraints  are  defined  for  this  document  type:  File  access  actions  are  restricted  to  Read.  File- 
directory  files  may  not  be  Written  or  Modified  (except  as  a  side  effect  of  actions  performed  on  individual  files 
contained  within  a  file  directory). 
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A.8.9 


Definition  of  transfer 


A.8.9,1 


Datatype  definition 


The  file  consists  of  zero  or  more  values  of  Datatypel  defined  in  table  13. 


A.3.9.2 


Presentation  data  values 


The  document  is  transferred  as  a  series  of  presentation  data  values.  Each  presentation  data  value  shall 
consist  of  one  value  of  the  ASN.1  data  type  "Datatypel,"  carrying  one  of  the  file  directory  entries  from  the 
document. 

All  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to  support  the  abstract 
syntax  name  "asnamel"  declared  in  table  13. 


A.8.9.3        Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  is  the  same  as  the  sequence  of  file  directory  entries  within  the 
Data  Unit  in  the  file. 


A.8.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules  named 
in  table  1 3  for  all  presentation  data  values  transferred.  Implementations  shall  optionally  support  other  named 
transfer  syntaxes. 


A.8.1 1      ASE  specific  specifications  for  FTAM 

Relaxation  is  allowed  to  any  bitstring  combination  of  the  document  type  parameter. 
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Annex  B  (normative) 
Constraint  Sets 

B.1      NBS  ordered  flat  constraint  set 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  constraint-set(4)  nbs-ordered-flat(l)} 

was  withdrawn  on  March  16,  1990.  It  was  replaced  with  the  object  NBS  ordered  flat  constraint  set  with  the 
Object  Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  constraint-set(4)  nbs-ordered-flat(l)} 
defined  in  part  9,  B.2. 

B.2      NBS  ordered  flat  constraint  set  definition 
B.2.1       Field  of  application 

The  NBS-ordered  flat  constraint  set  applies  to  files  which  are  structured  into  a  sequence  of  individual  FADUs 
and  to  which  access  may  be  made  on  an  FADU  basis  by  position  in  the  sequence. 

B.2.2       Basic  constraints 
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Table  14  -  Basic  constraints  for  NBS  ordered  flat 


Constraint  set  descriptor 

"NBS  ordered  flat  constraint  set" 

Constraint  set  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 
constraint-set(4)  nbs-ordered-flat(1 )} 

Node  name 

None 

File  access  actions 

Locate,  Read,  Insert,  Erase,  Replace 

Qualified  action 

None 

Available  access  contexts 

HA,  FA,  UA 

Creation  state 

Root  node  without  an  associated  data  unit 

Location  after  open 

Root  node 

Beginning  of  file 

Root  node 

End  of  file 

No  node  selected;  'previous'  gives  last  node  in  traversal  sequence, 
'current'and  'next'  give  an  error. 

Read  whole  file 

Read  in  access  context  FA  or  UA  with  FADU  identity  of  'begin'. 

Write  whole  file  (append) 
Write  whole  file  (replace) 

Transfer  the  series  of  leaf  FADUs  which  would  be  generated  by  reading 
the  whole  file  in  access  context  FA;  perform  the  transfer  with  an  FADU 
identity  of  'end'  and  a  file  access  action  of  'insert'. 

Transfer  the  series  of  leaf  FADUs  which  would  be  generated  by  reading 
the  whole  file  in  access-context  HA;  perform  the  transfer  with  FADU 
identity  'begin'  and  file  action  of  'replace'. 

B.2.3       Structural  constraints 


The  root  node  shall  not  have  an  associated  data  unit;  all  children  of  the  root  node  shall  be  leaf  nodes  and 
may  have  an  associated  data  unit;  all  arcs  from  the  root  node  shall  be  of  length  one. 


B.2.4       Action  constraints 

Insert:  The  < Insert >  action  is  allowed  only  at  the  end  of  file.lf  the  FADU  identity  is  "end"  the  new  node  is 
inserted  following  all  existing  nodes  in  the  file.  If  the  FADU  identity  is  "node  number,"  the  number 
must  be  at  least  one  greater  than  the  node  number  of  the  last  existing  node.  Any  nodes  between 
the  last  existing  node  and  the  new  node  are  empty,  i.e.,  nodes  without  data.  If  the  FADU  identity 
is  a  "node  number"  not  greater  than  that  of  the  last  existing  node,  an  error  will  occur.  The  location 
following  <  insert  >  is  "end." 

Erase:  The  Erase  action  is  only  allowed  at  the  root  node  to  empty  the  file,  with  FADU  identity  of  "begin." 
The  result  is  a  solitary  root  node  without  an  associated  data  unit. 
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NOTE  -  It  is  the  intention  when  using  this  constraint  set  to  allow  for  emptying  an  FADU,  i.e.,  leaving  an  FADU 
with  a  DU  of  data  length  0  (or  without  a  DU);  afterwards  data  may  be  reinserted  into  this  hole.  In  order  to 
empty  an  FADU,  the  <  Replace  >  operation  may  be  used  with  new  data  of  length  zero  (or  with  an  FADU  whose 
<data  exists>  bit  is  set  to  'false'  and  no  DU).  Refilling  the  hole  is  accomplished  by  a  <Replace>  operation 
with  the  new  DU  (or  with  the  new  FADU,  whose  <data  exists >  bit  is  set  to  'true'  and  the  new  DU). 


B.2.5       Identity  constraints 

The  FADU  identity  associated  with  the  file  action  shall  be  one  of  the  identities  "begin,"  "end,"  "first,"  "last," 
"current,"  "next,"  "previous"  or  a  "node  number"  greater  than  or  equal  to  one.  The  actions  with  which  these 
identities  can  be  used  are  given  in  the  following  table. 


Table  15  -  Identity  constraints  in  NBS  ordered  flat 


Action 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node  No. 

Locate 

valid 

valid 

valid 

valid 

valid 

valid 

valid 

valid 

Read 

whole 

leaf 

leaf 

leaf 

leaf 

leaf 

leaf 

Insert 

leaf 

leaf 

Erase 

whole 

Replace 

whole 

leaf 

leaf 

leaf 

leaf 

leaf 

leaf 
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Abstract  Syntaxes 

C.1      Abstract  Syntax  NBS-AS1 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  abstract-syntax(2)  nbs-as1(1)} 

was  withdrawn  on  March  1 6, 1 990.  It  was  replaced  with  the  object  Abstract  syntax  NBS-AS1  with  the  Object 
Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-as1(1)} 
defined  in  part  9,  C.3. 

C.2     Abstract  Syntax  NBS-AS2 

This  object  with  Object  Identifier 

{iso  identified-organization  icd(9999)  organization-code(l)  abstract-syntax(2)  nbs-as2(2)} 

was  withdrawn  on  March  16, 1990.  It  was  replaced  with  the  object  Abstract  syntax  NBS-AS2  with  the  Object 
Identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-as2(2)} 
defined  in  part  9,  0.4. 

C.3     Abstract  Syntax  NBS-AS1  definition 

Abstract  syntax  name:   {iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-asl(l)} 

"NBS  abstract  syntax  ASI" 

This  is  an  abstract  syntax  for  the  set  of  presentation  data  values,  each  of  which  is  a  value  of  the  ASN.l  type 
NBS-ASl.PrimType 


December  1991  (Stable) 
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NBS-AS1  DEFINITIONS  ::  = 
BEGIN 

PrimType  ::=  CHOICE 

{ 


INTEGER, 

BIT  STRING. 

BOOLEAN, 

lASString, 

GraphicString, 

GeneralStrIng, 

OCTET  STRING, 

UTCTIme, 

GeneralizedTlme, 

NULL, 

FloatingPolntNumber  } 


The  support  for  lASString  is  the  ISO  646,  IRV  GO 
character  set  and  the  ISO  646,  IRV  CO  set 
The  minimum  level  of  support  for  GraphicString  is 
the  ISO  646,  IRV  GO  character  set  and  the  8859-1 
GO  and  G1  sets. 

The  minimum  level  of  support  for  GeneralString  is 
the  ISO  646,  IRV  GO  character  set  and  the  8859-1 
GO  and  Gl  character  sets,  and  ISO  646,  IRV  CO  set. 


FloatingPolntNumber  ::=  [PRIVATE  0]     CHOICE  { 

finite  [0]  IMPLICIT  SEQUENCE 
{  Sign, 

mantissa  BIT  STRING, 

first  bit  must  be  1 
exponent  INTEGER}, 
infinity  [1]  IMPLICIT  Sign, 
signalling-nan  [2]  IMPLICIT  NaN, 
quiet-nan  [3]  IMPLICIT  NaN, 
zero  [4]  IMPLICIT  NULL  } 


Sign     ::=  INTEGER  {  positive  (0),  negative  (1)  } 

NaN     ::=  INTEGER 

END 


For  this  abstract  syntax  the  following  transfer  syntax  can  be  used 


{joint-iso-ccitt  asn1(1)  t)asic-encoding(l)} 
"Basic  Encoding  of  a  single  ASN.1  type" 
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NOTES 

1  The  mantissa  is  a  number  in  the  range  (1/2  <mantissa<1). 

2  The  value  is  equal  to  mantissa  *  2  ^"po"*"'. 

3  The  first  bit  in  the  mantissa  is  most  significant. 

4  See  IEEE  754  for  definitions  of  terminology,  such  as  NaN. 

5  A  minimum  length  range  (in  bits)  is  required  for  the  components  of  <FloatingPointNumber>,  as  follows: 
mantissa  1-23  bits,  and  exponent  0-8  bits. 

C.4     Abstract  Syntax  NBS-AS2  definition 

Abstract  syntax  name:  {  iso  identified -organization  olw(14)  ftamslg(5)  abstract-syntax(2)  nbs-as2(2)  } 

"NBS  file  directory  entry  abstract  syntax" 

This  is  an  abstract  syntax  for  the  set  of  presentation  data  values,  each  of  which  is  a  value  of  the  ASN.1  Type 
NBS-AS2.FileDirectoryEntry. 

NBS-AS2  DEFINITIONS  ::  = 
BEGIN 

FileDirectoryEntry  ::  =  [PRIVATE  2]  Read -Attributes 
Read-Attributes  ::  =  1808571 -FTAM. Read-Attributes 
END 

For  this  abstract  syntax  the  following  transfer  syntax  will  be  used 
{  joint-iso-ccitt  asn1(1)  basic-encoding(l)  } 
"Basic  Encoding  of  a  single  ASN.1  type" 


C.5     Abstract  Syntax  "FTAM  unstructured  text  abstract  syntax" 

This  abstract  syntax  is  defined  as  DataTypel  (File  Contents)  in  table  19  of  ISO  8571-2,  annex  B. 
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C.6     Abstract  Syntax  "FTAM  unstructured  binary  abstract  syntax" 

This  abstract  syntax  is  defined  as  DataTypel  (File  Contents)  in  table  21  of  ISO  8571-2,  annex  B. 
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Annex  D  (informative) 

FTAM-1  Document  Type  Tutorial 


D.I  Introduction 

This  annex  is  Informative.  It  does  not  specify  any  additional  requirements. 

Tlie  purpose  of  this  tutorial  is  to  describe  methods  to  convey  lines  of  text  in  a  FTAM-1  document  type. 

ISO  8571-2  defines  a  number  of  document  types  for  files.  One  of  these  document  types  is  FTAM-1.  ISO 
defines  the  FTAM-1  document  type  for  usage  with  files  that  contain  unstructured  text.  A  file  that  has  a 
document  type  of  FTAM-1  consists  of  one  FADU  that  consists  of  zero  or  more  character  strings.  In  order 
to  reduce  ambiguities  it  is  useful  to  assume  that  one  string  corresponds  to  one  Data  Element. 

FTAM-1  document  type  parameters  are  defined  in  ISO  8571-2  clause  B.I.  These  parameters  are  used  to 
define: 

the  allowed  character  sets  that  may  be  contained  in  the  strings  (universal-class-number); 
the  maximum  allowed  length  of  a  string  (maximum-string-length); 
the  significance  of  the  boundaries  of  string  (string-significance) 


D.2      Document  type  Parameters 


D.2.1  Universal-Class-Number 

The  universal-class-number  parameter  determines  the  character  sets  that  are  allowed  to  be  used  in  a  FTAM- 
1  file.  The  values  of  the  universal-class-number  parameter  are  ASN.1  types  whose  definition  can  be  found 
in  ISO  8824.  For  example,  GraphicString,  IA5String,  and  GeneralString  are  some  ASN.1  universal  types.  The 
important  thing  for  this  discussion  is  that  some  string  classes  allow  only  graphic  characters  to  be  used  while 
other  string  classes  allow  both  graphic  and  control  characters  to  be  used.  (Control  characters  include 
"format  effector"  characters  such  as  carriage  return  <CR>  and  line  feed  <LF>). 


D.2.2  Maximum-String-Length 

The  maximum-string-length  parameter  determines  the  maximum  number  of  characters  allowed  in  a  string 
of  the  FTAM-1  file.  It  does  not  determine  the  maximum  number  of  octets  allowed  in  the  string. 

GeneralStrings  illustrate  how  the  number  of  octets  in  a  string  can  differ  from  the  number  of  characters  in 
a  string.  GeneralStrings  can  contain  escape  sequences  that  are  used  for  purposes  such  as  invoking  different 
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character  sets.  An  escape  sequence  is  considered  to  be  a  bit  string,  not  a  character  string.  Therefore,  the 
combined  length  of  any  escape  sequences  contained  in  a  GeneralString  contributes  to  the  number  of  octets 
in  the  GeneralString  but  does  not  contribute  to  the  number  of  characters  in  the  GeneralString. 

The  length  value  of  the  ASN.1  encoding  of  a  character  string  always  reflects  the  number  of  octets  in  the 
character  string.  This  value  will  always  be  greater  than  or  equal  to  the  number  of  characters  in  the  string. 
The  ASN.1  string  must  be  processed  to  determine  the  actual  number  of  characters  in  the  string. 

OIW  FTAM  Phase  2  agreements  state  that  a  conformant  FTAM  implementation  must  support  a  maximum- 
string-length  parameter  of  at  least  134  for  a  FTAM-1  file  (see  part  9  clause  10).  There  is  no  minimum 
requirement  for  maximum-string-length  in  the  FTAM  phase  3  agreements.  The  minimum  requirement  implies 
that  a  minimally  conformant  OIW  FTAM  responding  implementation  will  not  accept  a  FTAM-1  file  whose 
actual  maximum-string-length  parameter  has  a  value  greater  than  134.  The  relaxation  rules  for  FTAM-1  files 
allow  a  FTAM-1  file  to  be  opened  for  read  using  a  maximum-string-length  parameter  that  is  greater  than  or 
equal  to  the  value  of  the  maximum-string-length  file  attribute  actually  associated  with  the  file,  a  smaller  value 
is  not  allowed  (see  ISO  8571-2  B.I  clause  11.1.1.2).  This  implies  that  a  minimally  conformant  OIW  FTAM 
initiating  implementation  can  not  read  a  FTAM-1  file  whose  actual  string  length  parameter  has  a  value  greater 
than  134. 

To  increase  interoperability,  a  sending  FTAM  system  should  be  able  to  divide  a  file  with  string-significance 
of  not-significant  into  strings  of  no  more  than  134  characters.  A  receiving  FTAM  system  should  be  able  to 
use  the  strings  to  form  the  file  which  was  sent.  If  a  file  has  a  maximum-string-length  associated  with  it  that 
is  greater  than  134  intenA/orking  will  not  be  possible  with  a  minimally  conformant  system. 


D.2.3  String-Significance 

The  string-significance  parameter  determines  the  significance  of  the  character  strings  (semantics  of  string 
boundaries).  Fixed  string-significance  means  that  each  string  contains  exactly  the  number  of  characters 
defined  by  the  maximum-string-length  parameter.  Variable  string-significance  means  that  the  length  of  each 
string  is  less  than  or  equal  to  the  maximum-string-length  parameter.  When  string-significance  is  fixed,  then 
maximum-string-length  must  be  present.  For  string-significance  of  fixed  or  variable  the  boundaries  of  the 
character  strings  are  preserved  and  contribute  to  the  document's  semantic.  A  value  of  not-significant  means 
that  the  length  of  each  string  is  less  than  or  equal  to  the  maximum-string-length  parameter  and  that  the 
boundaries  of  the  character  strings  are  not  necessarily  preserved  when  the  file  is  stored  and  do  not 
contribute  to  the  document's  semantics.  In  this  case,  string-significance  may  not  be  maintained,  thus  the 
sender  entity  explicitly  declares  that  string  boundaries  have  no  meaning. 

Note  the  OIW  FTAM  Phase  2  agreements  require  the  support  of  only  the  not-significant  value  for  string- 
significance.  Fixed  and  variable  string-significance  are  outside  the  scope  of  the  Phase  2  agreements,  but 
are  required  in  the  Phase  3  agreements. 

It  is  in  the  area  of  not-significant  strings  where  most  interoperability  problems  have  occurred. 

NOTE  -  the  difference  between  variable  significance  and  not-significant  significance.  If  a  file  has  a  significance 
of  fixed  or  variable,  it  is  the  responsibility  of  any  storer  of  the  file  to  "remember"  where  the  boundaries  of  each 
character  string  are  located  within  the  file.  The  storer  of  a  file  with  a  significance  of  not-significant  has  no  such 
responsibility.  For  example,  when  working  with  a  not-significant  file,  the  sending  application  may  find  that  512 
byte  chunks  of  data  is  convenient  and  useful.  The  512  byte  size  may  have  no  relation  to  the  file  layout,  but  is 
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easy  to  read  from  disk. 


D.3      New  Line  Function 

When  a  sequence  of  characters  are  being  displayed  on  a  character  imaging  device,  e.g.,  printer  or  video 
display  terminal  the  term  "new  line  function"  is  used  to  mean  the  repositioning  of  the  current  character 
display  position  one  row  down  and  back  to  column  one.  A  new  line  function  may  be  implemented  in  a 
variety  of  ways.  A  UNIX  system  implements  the  new  line  function  with  a  <LF>  character  (sometimes  called 
<NL>).  A  MS-DOS  system  implements  the  new  line  function  with  a  <CR><LF>  character  sequence.  A 
typical  word  processor  will  implement  a  new  line  function  as  a  "wrap  around"  function  that  depends  upon 
a  defined  page  width.  A  record  oriented  file  system  may  interpret  an  end  of  record  condition  as  implying 
a  new  line  function. 

ISO  suggests  (see  ISO  646  clause  4.1.2.2)  that  a  new  line  function  be  accomplished  with  a  <CR><LF> 
combination.  If  there  is  a  prior  arrangement, e.g.,  a  bilateral  agreement,  between  a  sender  and  a  receiver, 
and  only  in  this  case,  may  a  vertical  format  effector,  i.e.,  a  <  LF>  be  used  to  accomplish  a  new  line  function. 
The  01 W  FTAM  agreements  contain  no  such  prior  arrangement  (see  01 W  Part  9  clause  10.1.2). 

It  is  strongly  suggested  that  files  being  sent  to  a  remote  FTAM  implementation  represent  the  local  new  line 
function  as  a  <CR><LF>  pair  and  files  received  from  a  remote  FTAM  implementation  have  <CR><LF> 
pairs  converted  to  the  local  new  line  function.  See  D.5  for  the  reasons  for  this  suggestion. 

It  is  important  to  realize  that  a  new  line  function  represents  a  display  positioning  function  and  it  does  not 
represent  anything  more  that.  A  new  line  function  is  not  intended  to  act  as  either  a  string  terminator  or  a 
string  separator. 


D.4      Character  Strings  Versus  Lines 

A  line  of  characters  is  generally  considered  to  be  a  sequence  of  graphic  characters  followed  by  a  new  line 
function  (or  possibly  by  an  end  of  line  condition). 

A  character  string  is  simply  that,  a  string  of  characters  from  one  or  more  character  sets.  Characters  within 
a  string  come  from  allowed  character  sets.  It  is  the  "universal-class-number"  parameter  defined  in  ISO  8571  -2 
B.1  that  determines  which  character  sets  may  be  used  to  compose  a  string.  For  example,  a  GraphicString 
consists  of  characters  from  any  graphic  character  set  but  may  not  contain  characters  from  a  control 
character  set  ( it  can  not  contain  format  effectors);  a  GeneralString  consists  of  characters  from  any  graphic 
character  set  and  characters  from  any  control  character  set  ( it  can  contain  format  effectors). 

Text  files  will  be  transferred  using  the  Document  type  FTAM-1 .  The  supported  character  sets  and  their 
recommended  line  delimiters  are: 

lASString         (line  boundaries  via  format  effectors,  preferably  <CR><LF>) 

GeneralString    (i.e.  ISO  646  International  Reference  Version  and  ISO  8859-1.  Line  boundaries  via 
format  effectors,  preferably  <CR><LF>) 

VisibleString     (IA5  String  without  control  characters,  line  boundaries  via  Data  Element  boundaries) 
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GraphicString    (i.e.  ISO  646  International  Reference  Version  without  control  characters  and  ISO 
8859-1,  line  boundaries  via  Data  Element  boundaries) 


NOTE  -  A  string  is  really  a  language  (programming  or  otherwise)  concept.  File  systems  generally  have  no 
concept  of  a  string,  although  a  file  system,  especially  a  record  oriented  file  system  may  have  some  concept 
of  a  line. 

The  standard  gives  no  relation  between  character  string  and  a  line  of  characters.  A  character  string  may 
contain  a  portion  of  a  line  of  characters  or  it  may  contain  multiple  lines  of  characters.  A  character  string  can 
contain  zero,  one,  or  many  <CR><LF>  pairs.  For  those  character  sets  which  include  format  effectors,  a 
character  string  may  or  may  not  end  with  a  <CR><LF>  pair.  In  fact,  an  entire  file  of  character  strings  may 
not  contain  a  single  <CR><LF>  pair,  even  when  those  characters  are  allowed  to  be  used  in  the  character 
strings. 


The  following  figure  is  an  example  of  how  lines  of  text  could  be  conveyed  using  lASString  or  GeneralString 
with  string-significance  of  not-significant. 


String-1 

String-2 

String-3 

String-4 

String-5 

Line-1 

<CR><LF> 

Line-2 

<CR><LF> 

Line-3 

<CR>  <LF> 

Line-4 

<CR><LF> 

Line-S 

<CR><LF> 

The  following  figure  is  an  example  of  how  lines  of  text  could  be  conveyed  using  VisibleString  or 
GraphicString  with  string-significance  of  fixed  or  variable. 


String-1 

String-2 

String-3 

String-4 

String-5 

Line-1 

Line-2 

Line-3 

Line-4 

Line-5 

D.5     Mapping  FTAM-1  Files  to  Real  Files 

The  lack  of  equivalence  between  a  line  of  characters  and  a  character  string  can  cause  implementation 
problems.  It  is  common  for  a  record  oriented  file  system  to  store  a  line  of  characters  as  a  record.  How  does 
such  a  system  decide  how  large  a  record  to  allocate  for  a  line  of  characters?  A  line  of  characters  may  be 
contained  in  a  part  of  one  string,  one  or  more  strings,  or  it  may  actually  consist  of  an  entire  file.  How  does 
such  a  system  identify  the  end  of  a  line  (record)?  It  must  scan  the  string  for  a  <CR><LF>  pair  (or  end  of 
transmission)  and  probably  remove  the  <CR><LF>  before  storing  a  record.  What  happens  if  the  line  is 
bigger  than  the  size  of  the  record  allocated?  The  system  would  likely  break  the  string  and  store  it  in  the 
available  record  size.  In  this  case,  the  FTAM-1  document  type  should  not  be  used  to  transfer  this  file  when 
the  sender  is  not  sensitive  to  the  receiver's  limitations. 

Another  problem  can  occur  when  a  system  whose  new  line  function  is  implemented  by  a  <CR><LF>  pair 
sends  a  file  to  a  system  whose  new  line  function  is  implemented  by  <LF>.  For  example,  a  MS-DOS  system 
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could  send  a  file  that  contains  <CR><LF>  pairs  and  also  contains  single  <LF>  characters  to  a  UNIX 
system.  The  UNIX  system  would  likely  translate  both  <CR><LF>  and  <LF>  to  UNIX  new  line  functions, 
i.e.  a  <LF>.  In  this  case,  the  RAM-1  document  type  should  not  be  used  to  transfer  this  type  of  file. 


D.6     Printing  or  Displaying  a  File  without  Format  Effectors 

There  is  no  relation  between  a  character  string  and  a  line  of  characters  (see  ISO  8571  -2  B.1  clause  7)  except 
when  character  strings  that  come  from  character  sets  that  do  not  contain  format  effector  characters  (for 
example,  VisibleStrings  and  GraphicStrings)  are  transferred  to  a  device  such  as  a  printer.  In  this  case  the 
end  of  a  string  implies  the  invocation  of  the  device's  new  line  function.  This  means  that,  in  this  case,  a  string 
is  equivalent  to  a  line. 

The  rendition  of  such  a  file  made  of  character  strings  belonging  to  a  set  that  does  not  contain  format  effector 
characters  (for  example,  VisibleString,  and  GraphicString)  to  be  transferred  first  to  disk  and  then  to  a 
character  imaging  device  might  not  be  equivalent  to  the  rendition  of  the  same  file  transferred  directly  to  a 
character  imaging  device. 


72 


^  Stable  Implementation 

Agreements  for  Open  Systems 
Interconnection  Protocols: 
Part  1 0  -  FTAM  Phase  3 


Output  from  the  December  1991  OSI  Implementors' 
Workshop 


SIG  Chair: 
SIG  Editor: 


Joe  Mohen,  Proginet 

Larry  Friedman,  Digital  Equipment  Corporation 


PART  10  -  FTAM  Phase  3 


December  1991  (Stable) 


Foreword 
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previously  given.  References  to  Part  9  are  made  in  this  part. 

Future  changes  and  additions  to  this  version  of  these  I mplementor  Agreements  will  be  published  as  change 
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1  Scope 

These  Phase  3  Agreements  specify  additional  functionality  to  the  FTAM  Phase  2  Agreements.  These 
additional  functions  include: 

Further  specifications  of  document  types; 

Specification  for  Restart  Data  Transfer  and  Recovery  functional  units; 

Specification  of  FADU  Locking  functional  unit; 

More  details  on  Access  Control  and  Concurrency  Control. 

All  Phase  2  systems  are  upward  compatible  to  a  Phase  3  system  and  can  therefore  intenA/orl<  with  it,  if  the 
additional  functions  are  negotiated  out  (e.g.,  use  of  Recovery)  or  not  used  for  the  interconnection  (e.g., 
additional  features  for  document  types). 


2     Normative  References 

Amendments  and  corrigenda  to  the  base  standards  referenced:  See  annex  G  for  a  complete  list  of  these 
documents. 

ISO  8571-1:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  [Management  Part  1:  General  Introduction 

ISO  8571-2:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  [Management  Part  2:  Virtual  Filestore  Definition 

ISO  8571-3:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
Transfer,  Access  and  Management  Part  3:  The  File  Sen/ice  Definition 

ISO  8571-4:  1988(E),  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File 
;  I       Transfer,  Access  and  (Management  Part  4:  File  Protocol  Specification 
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3  Status 

These  FTAM  Phase  3  Agreements  were  completed  December  15,  1989.  No  further  enhancements  will  be 
made  to  this  version  (see  also  next  clause  ERRATA). 

The  following  tables  summarize  the  functions  and  features  which  are  defined  for  FTAM  Phase  3  in  addition 
to  the  FTAM  Phase  2  specifications.  They  also  state  the  degree  of  possible  interworking  and  the  backward 
compatibility. 


Table  1  -  Phase  2/Phase  3  Interworking 


Additional  requirements  in  FTAM  phase  3 

Backward  compatibility  to 
FTAM  phase  2 

FTAM-1 :  GraphicString.VisibleString 
FTAM-2:  VisibleString 
concurrency-control  parameter  for  Initiator 
create-password  parameter  for  Initiator 

Profile  Ml. 3:  Requires  support  of 

(1)  -T  service  class  including  Limited  File 
Management  FU,  Enhanced  FM  FU; 

TM  service  class  including  Enhanced  FM  FU  or 

(2)  -A  service  class  including  Limited  File 
Management  FU,  Enhanced  FM  FU 

full  backward  compatibility  if  the 
additional  features  of  Phase  3 
are  not  being  used  (character 
sets  in  FTAM-1,  -2),  or  not 
requested  by  an  Initiator 
(functional  units)  or  not 
required  by  a  Responder 
(parameters)  not  requested  by 
an  Initiator  (functional  units) 
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Table  1  -  Phase  2/Phase  3  Interworking  (continued) 


Additional  optional  features  in  FTAM  phase  3 

Backw/ard  compatibility 
to  FTAM  phase  2 

FTAM-2:  GeneralString,  lASString 

FTAM-4 

NBS-8  in  T2.3,  A1.3 

NBS-9  in  A1.3,  A2.3 

NBS-10 

NBS-11 

NBS-12 

Recovery  functional  unit 

Restart-data-transfer  functional  unit 

FADU-locking  functional  unit  and  FADU-lock  parameters  in  A1 .3,  A2.3 
Concurrency-control  parameters  for  Responder 

full  backw/ard  compatibility  if  the 
additional  features  of  Phase  3  are  not 
requested,  negotiated  out  or  not  being 
used 

create-password  parameter  for  Responder 

location-field  of  access-control  element 

suggested-delay  term  of  diagnostic  parameter  supported  conditionally  on 
Recovery  functional  units 
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Table  1  -  Phase  2/Phase  3  Interworking  (concluded) 


Relaxation  for  FTAM  phase  3 

Backward  compatibility  to  FTAM  phase 
2 

Profiles  A1 .3,  A2.3  do  not  require  transfer  service  class 

no  minimum  requirements  for  maximum-string-length  parameters  for  document 
types 

if  T  service  class  not  being  used 

if  a  Phase  3  system  stays  below  this 
minimum  requirement 

4  Errata 

Table  2  -  List  of  Errata 


No.  of 
errata 

Type 

Referenced 
document 

Clause 

Description 

CP  3/91-1 

Editorial 

NIST-SP  500-183 

All 

Update  to  ISO  style.  General 
formatting  and  error  corrections. 
Alignment  with  the  wording  of  the  ISP. 
Consistent  naming  conventions. 

CP  6/91-1 

Editorial 

NIST-SP  500-183 

8.6.1 

A.13.9.1.2 
A.13.9.1.3 
A.13.9.1.4 

Previous  errata  changed  the  Profile 
Requirements  List  (PRL)  support  of 
Concurrency  Control  from  "m"  to 
"o".  This  change  was  not  reflected. 

Alignment  with  the  ISP. 
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No.  of 
errata 

Type 

Referenced 
document 

Clause 

Description 

CP  9/91-1 

CP  9/91-2 
CP  9/91-2 

CP  9/91-3 
CP  9/91-4 

CP  9/91-5 

Editorial 

NIST  SP  500-183 

Table  4 

Table  5 
Table  8 

Clause  2 

A.12.16.1 
A.12.16.5 
A.12.17.1 
A.12.17.5 

Include  "FTAM"  in  object  descriptor 
for  consistency  with  other  OIW 
FTAM  objects. 

Add  definition  for  Datatype3 

Delete  last  line  of  Write  Whole  File 
[previous  change  incomplete]. 

Add  reference  to  corrigenda. 

Support  level  from  "o"  to  "m".  Add 
note  that  must  support  at  least  one 
action.  Add  note  about  supporting 
at  least  one  optional  FU. 

A.13.6.1 
A.13.6.2 

Change  to  spelling  of  ASN.1  text 
types. 

CP  9/91-6 

C.2.7 

C.2.9.1 

C.2.9.2 

Changes  to  add  Datatypes  to  text 
descriptions 

CP  9/91-7 

C.I. 11.1 
C.2.11.1 
C.3.11.1 

"Structural  Simplification"  to 
"Simplification" 

CP  9/91-8 

E.I 
E.2 

Changed  "will"  to  "can" 

E.3 

CP  9/91-9 

Annex  B 

Added  Editors  note  of  intention  to 
remove  object  definitions  when  the 
ISP  is  published. 

CP  9/91- 
10 

Added  Annex  G 

New  annex  to  list  corrigenda 
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5  Conformance 

In  addition  to  tlie  specific  requirements  specified  in  tfie  following  subclauses,  conformance  to  this  Phase 
3  specification  requires 

conformance  to  ISO  8571:  1988 

conformance  to  Phase  2  FTAM,  unless  specified  otherwise  in  this  part  10. 

The  access  Profiles  A1.3  and  A2.3  do  not  include  the  requirement  for  transferring  files  using  the  File 
Transfer  service  class. 


6  Assumptions 

FTAM  Phase  3  Agreements  specify  additional  functionality  to  the  Implementation  Profiles  T1,  T2,  T3,  A1, 
A2,  and  Ml  as  defined  in  the  FTAM  Phase  2  Agreements.  So  all  definitions  and  requirements  for  these 
Implementation  Profiles  apply  also  to  the  Phase  3  Agreements. 


7     Filestore  Agreements 


7.1      Document  Types 

In  addition  to  the  Phase  2  Document  Type  Agreements  the  document  types  FTAM-4  (see  ISO  8571-2, 
Annex  B)  and  NBS-10,  NBS-11,  NBS-12  (see  Annex  0)  are  defined  for  optional  support. 

Table  2  gives  the  support  levels  for  all  document  types  with  respect  to  the  Implementation  Profiles. 

For  FTAM-1,  RAM-2,  FTAM-3  and  FTAM-4  the  supported  parameter  values  for  <  universal  class 
number>  and  <string  significance >,  respectively  are  listed.  Other  values  are  outside  the  scope  of  these 
Agreements.  No  restriction  or  minimum  requirement  is  defined  for  the  <  maximum  string  length  > 
parameter  of  these  document  types. 
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Table  3  -  Implementation  Profiles  and  Document  Types  -  FTAM-1  Through  FTAM-4 


Implementation  Profile 
(Note  1) 

Document 
Type 

Universal  Class  Number 
(Notes  1 ,3,4,5) 

String  Significance 

T1.3,  T2.3,  T3.3,  A1.3,  A2.3 

FTAM-1 

GraphicString  (25) 

'variable'  'fixed' 

VisibleString  (26) 

'variable'  'fixed' 

GeneralString  (27) 

'not-significant' 

IA5String  (22) 

'not-significant' 

FTAM  9 

(^ranhir^trinn  (0R\ 
oi  dpi  iitjoii  If  ly  \^^/ 

VisibleString  (26) 

'not-significant' 

[GeneralString  (27)] 

'not-sianificant' 

[lASString  (22)] 

'not-significant' 

T1.3,  T2.3,  T3.3,  A1.3,  A2.3 

FTAM-3 

'not-significant' 

[T2.3],  [T3.3],  [A1.3], 
[A2.3] 

FTAM-4 

'not-significant' 

Table  3  -  Implementation  Profiles  and  Document  Types  -  NBS-6 

Through  NBS-11  (continued) 

Implementation  Profile  (Note  1) 

Document  Type 

[T2.3],  T3.3,  [A1.3],  A2.3 

NBS-6 

[T2.3],  T3.3,  [A1.3],  A2.3 

NBS-7 

[T2.3],  T3.3,  [A1.3],  A2.3 

NBS-8 

[T1.3],  [T2.3],  [T3.3],  [A1.3],  [A2.3] 

NBS-9 

[T2.3],  [T3.3],  [A1.3],  [A2.3] 

NBS-10 

[T2.3].  [T3.3],  [A1.3],  [A2.3] 

NBS-11 
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Table  3  -  Implementation  Profiles  and  Document  Types  -  NBS-12  (concluded) 


Implementation  profile 
(Note  1) 

Document  type 

Universal  class  number 

Character-set  escape 
sequences  as  defined  for 
reg.  numbers 
CO        GO  G1 

String-significance 

[T2.3].  [T3.3], 

[A1.3], 

[A2.3] 

NBS-12 
See  Note  6 

lASString  [22] 

(parameter  absent) 

'variable'  'fixed' 

GraphicString  [25] 

(parameter  absent) 

'variable'  'fixed' 

GraphicString  [25] 

6  100 

'variable'  'fixed' 

VisibleString  [26] 

(parameter  absent) 

'variable'  'fixed' 

GeneralString  [27] 

(parameter  absent) 

'variable'  'fixed' 

GeneralString  [27] 

1          6  100 

'variable'  'fixed' 

NOTES 

1  Brackets  around  a  Profile  designator  or  a  parameter  value  indicate  that  the  respective  document  type  or  parameter  value  is 
optionally  supported  in  this  Implementation  Profile. 

2  The  support  level  for  document  types  in  Implementation  Profile  Ml. 3  depends  on  the  T-  or  A-lmplementation  Profile,  in 
conjunction  with  w/hich  Ml. 3  is  implemented. 

3  The  support  for  IA5  String  is  the  ISO  646,  IRV  GO  character  set  and  the  ISO  646,  IRV  CO  set. 

4  The  minimum  level  of  support  for  Graphic  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO  and  G1  sets. 

5  The  minimum  level  of  support  for  General  String  is  the  ISO  646,  IRV  GO  character  set  and  the  8859-1  GO  and  G1  sets,  and  ISO 
646,  IRV  CO  set. 

6  If  the  Character-Set  parameter  is  absent,  the  following  defaults  apply: 


Universal-class-number 

Default  registration  numbers 

CO 

GO 

G1 

IA5String 

[22] 

1 

2 

GraphicString 

[25] 

2 

VisibleString 

[26] 

2 

GeneralString 

[27] 

1 

2 
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Registration  number 

Content 

Escape  Sequence 

1 

2 
6 

100 

CO  set  of  ISO  646 
ISO  646,  IRV 

ISO  646,  USA  Version-X  3.4  -  1968  (Left-hand  part  of  ISO  8859- 
1) 

Right-hand  part  of  Latin  Alphabet  No  1  ISO  8859-1,  ECMA-94 

ESC  2/1  4/0 
ESC  2/8  4/2 
ESC  2/13  4/1 

7.2      FADU  Identities 

In  addition  to  the  Phase  2  FADU  Identity  Agreements  the  following  is  specified: 

For  the  document  type  NBS-1 1  used  in  conjunction  with  the  Transfer  service  class  or  the 
Transfer  and  Management  service  class,  the  support  of  the  FADU  identities  of  "current,"  "next," 
"previous"  and  "end"  is  outside  the  scope  of  these  Agreements. 


7.3      Access  Control  Attribute 

The  location  field  of  access  control  element  is  optionally  supported.  It  is  the  implementor's  choice  which 
combinations  of  fields  in  an  access  control  element  are  supported.  The  ACE  combination  should  be 
stated  in  the  PICS. 


8     Protocol  Agreements 


8.1      Implementation  Profile  Ml  .3 

The  functions  defined  for  the  Implementation  Profile  Ml. 3  shall  always  be  implemented  in  conjunction 
with  one  or  more  of  the  Implementation  Profiles  T1.3,  T2.3,  A1.3,  or  A2.3.  The  service  classes  and 
functional  units  that  shall  be  implemented  are  specified  in  Annex  A,  A.  12.4  and  A.  12.5. 

For  an  implementation  supporting  the  Profile  M1.3  in  conjunction  with  T1.3  or  T2.3,  any  of  the  service 
classes  Transfer,  Management  or  (Transfer,  Management,  Transfer-and-Management)  may  be  requested 
and  any  of  the  classes  Transfer,  Management,  Transfer-and-Management  may  be  responded  on  F- 
INITIALIZE. 

For  an  implementation  supporting  the  Profile  Ml. 3  in  conjunction  with  A1.3  or  A2.3,  any  of  the  service 
classes  Access  or  Management  may  be  requested  and  responded  on  F-INITIALIZE. 
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8.2      Functional  Units 

For  FTAM  Phase  3  implementations  Recovery  and  Restart  Data  Transfer  are  optionally  supported. 
FADU  locking  is  optionally  supported  for  Implementation  Profiles  A1.3  and  A2.3. 


8.3      Implementation  Information  Parameter 

In  addition  to  the  Agreements  as  specified  for  FTAM  Phase  2,  part  9  clause  12  ,  the  following  value  is 
defined 

NBS-Phase3. 


8.4  F-Check 

In  order  to  maximize  interoperability,  implementations  of  FTAM  service  providers  should  not  restrict  the 
amount  of  data  transmitted  between  successive  F-CHECK  requests  to  a  single  quantity.  Variations  in  the 
amount  of  data  transmitted  between  checkpoints  may  be  required  to  accommodate  differences  in  real 
end  systems  supporting  FTAM  Virtual  Filestores  and/or  in  the  communications  media  underlying  FTAM 
associations.  It  is  required  that  all  FTAM  implementations  are  able  to  receive  at  least  one  PSDU 
between  checkpoints. 


8.5      Error  Recovery 

Procedures  for  Class  I,  II  and  III  errors  are  defined  and  supported  for  FTAM  Phase  3  implementations.  It 
is  the  implementor's  choice  whether  to  handle  class  I  errors  using  F-RESTART  PDUs  or  whether  to  use 
the  class  II  error  procedure. 


8.5.1        Docket  Handling 

When  a  class  III  error  occurs,  the  length  of  time  a  docket  is  maintained  is  determined  by  the  local 
system.  Recovery  from  a  class  III  error  is  only  possible  as  long  as  both  end  systems  maintain  the 
docket. 

It  is  also  a  local  decision  how  many  dockets  can  be  maintained  simultaneously. 


8.5.2       Parameters  for  Error  Recovery 

The  following  information  is  given: 

The  semantics  of  the  <FTAM  quality  of  service>  parameter  is  as  defined  in  ISO  8571;  including 
the  local  knowledge  of  FERPM; 
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No  minimum  requirement  for  tlie  <  checkpoint  window  >  parameter  or  tlie  checkpoint  size  is 
defined; 

For  the  <  recovery  mode>  parameter  of  F-OPEN,  the  values  'none'  and  'at-start-of-transfer'  are 
supported.  The  value  'at-any-active-checkpoint'  is  optionally  supported.  If  recovery  mode  'at- 
start-of-transfer'  is  negotiated,  no  F-CHECK  shall  be  issued.  When  recovering  at  the  start  of  the 
transfer,  the  <  recovery  point >  value  of  0  shall  be  used; 

It  is  required  that  Responders  implementing  the  Restart-data-transfer  or  the  Recovery  functional 
unit  must  be  able  to  negotiate  <  recovery  mode>  parameter  to  a  value  other  than  'none'; 

For  the  <diagnostic>  parameter  of  F-INITIALIZE,  F-P-ABORT  and  F-RECOVER  PDUs,  the  term 
<  suggested  delay >  shall  be  supported  If  the  Recovery  functional  unit  is  implemented.  The 
Basic  FERPM  should  wait  at  least  the  amount  of  time  as  given  by  the  <  suggested  delay  >  term 
before  attempting  to  recover. 


8.6      Concurrency  Control 


8.6.1        Concurrency  Control  to  whole  file 

If  <  concurrency  control  >  parameters  are  supported,  details  of  their  possible  usage  is  a  local  matter  and 
shall  be  specified  in  the  PICS. 

Default  values  for  concurrency  control  are  as  specified  for  FTAM  Phase  2  Agreements. 

No  minimum  requirement  is  defined  for  <  concurrency  control  >  parameter  values. 

For  a  first  accessor  either  the  specified  concurrency  locks  or  the  default  values  are  assigned.  For  a 
subsequent  accessor  the  access  to  a  file  is  granted  only  if  this  concurrency  control  requirement,  as 
specified  in  this  concurrency  control  parameter  or  given  by  the  default  values,  can  be  met.  Otherwise 
the  subsequent  request  shall  be  rejected. 


8.6.2        FADU  Locking 

FADU  locking  functional  unit  and  the  respective  <FADU  lock>  parameters  are  optionally  supported  for 
the  Implementation  Profiles  A1.3  and  A2.3. 

It  is  understood  that  ISO  8571-4  Clause  18.4  also  applies  to  FADU  locks;  that  means  that  as  long  as  a 
docket  is  maintained,  FADU  locks  locking  any  FADUs  recorded  in  that  docket  should  be  maintained. 
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8.7      Create  Password 

The  < create  password >  parameter  for  an  implementation  acting  as  an  Initiator  is  supported.  This 
parameter  is  optionally  supported  for  an  implementation  acting  as  a  Responder. 


8.8      Initiator  Identity,  Passwords  and  Account 

An  Initiator  must  be  capable  of  sending  and  not  sending  the  parameters  < initiator  identity >,  <filestore 
password  >,  <  access  passwords  >  and  <  create  password  >  to  satisfy  the  requirements  of  the 
Responder. 

The  contents  of  the  <  initiator  identity >,  < filestore  password  >,  <  access  passwords  >,  <  create 
password >  and  <account>  parameters  shall  be  in  the  convention  of  the  responding  implementation. 


9     Range  of  Values  for  Integer-Type  Parameter 

in  addition  to  the  parameters  specified  for  FTAM  Phase  2  under  the  same  heading,  the  parameters 


F-RECOVER  request 

bull<-transfer-number 
NBS-AS3 
NBS-Node-Name 

starting-fadu 

fadu-count 

may  be  encoded  so  that  the  length  of  its  contents  octets  is  no  more  than  eight  octets. 
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Editor's  Note  -  The  page  numbering  of  the  PICs  tables  may  not  be  aligned  with  the  text  of  this 
document.  The  reason  for  this  problem  is  that  the  PICs  tables  are  coded  using  a  different  wordprocessor. 
e  n      The  tables  are  being  converted,  but  until  this  is  completed  the  page  numbering,  and  format  of  the  tables 
may  be  aligned  with  the  text  of  this  document. 


In  the  event  of  a  discrepancy  becomming  apparent  in  the  body  of  tliese  agreements  and  the  tables  in 
this  annex,  this  annex  is  to  take  precedence. 

Editor's  Note  -  Delete  lines  A.13.9.1.2,  A.13.9.1.3,  A.13.9.1.4,  when  the  PICS  tables  are  converted  to 
,.  WordPerfect  Version  5.1  format. 

Editor's  Note  -  Change  table  A.5  to  reference  Annex  G.  See  ISO/IEC  ISP  10607-4:1990  A.5.  When 
Annex  A  is  converted  to  Wordperfect  V5.1. 


Editor's  Note  -  A.12.16.1,  A.12.16.5,  A.12.17.1,  and  A.12.17.5  replace  the  "o*  with 'm'  in  the  A1.3  column. 
Add  a  note  to  tables  A.  12. 16  and  A.  12. 17  Tor  the  profile  A1.3,  the  support  of  at  least  one  of  insert,  replace, 
or  extend  is  required."  Also  add  a  note  to  tables  A.12.16  and  A.12.17  °  For  profiles  T1.3  and  T2.3,  the 
support  of  at  least  one  of  read,  insert,  replace  or  extend  is  required."  When  Annex  A  is  converted  to 
WordPerfect  V5.1. 


Editor's  Note  -  A.13.6.1,  and  A.13.6.2  change  parameter  names  to  "Universal  time,"  "Generalized  time," 
"lASString,"  "Boolean,"  "Bit,"  "Integer."  When  Annex  A  is  converted  to  WordPerfect  V5.1. 


December  1991  (Stable) 
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Annex  A 

(normative) 

Profile  Requirements  List  for  NIST  OIW  FTAM  Phase  3 

A.O  Introduction 

This  annex  to  NIST  FTAM  Phase  3  Agreements  defines  a  Profile  Requirements  List  (PRL)  for  the  Implementation 
Profiles 

T1.3    -     Simple  File  Transfer 
T2.3    -     Positional  File  Transfer 
A1.3    -     Simple  File  Access 
Ml. 3   -  Management 

This  annex  specifies  the  constraints  and  characteristics  of  NIST  OIW  FTAM  Phase  3  on  what  shall  or  may  appear  in 
the  supplier  columns  of  an  FTAM  Phase  3  PICS.  This  annex  is  completely  based  on  ISO  8571-5.  It  uses  only  a 
selection  of  the  tables  from  ISO  8571-5  which  are  necessary  for  the  specification  of  the  FTAM  Phase  3  status,  and 
retains  their  numbering,  in  order  to  facilitate  for  a  supplier  to  fill  in  the  respective  PICS  Proforma. 

This  annex  is  a  summary  of  all  definitions  of  FTAM  Phase  3  as  they  appear  in  the  Stable  Implementation  Agree- 
ments for  OS!  Protocols,  Version  4  Edition  1,  December  1990,  parts  9  and  10. 


A. 0.1  Conformance  requirement  of  Base  Standards 

The  D-column  of  clauses  A.I  to  A.13  specifies  the  conformance  requirement  of  the  base  standards  ISO  8571,  as 
written  in  ISO  8571-5.  The  definitions  apply  as  defined  in  ISO  8571-5  clause  8.1  : 

m  -    mandatory  support 
o     -  optional  support 
f     -  full  support  of  attributes 
p     -  partial  support  of  attributes 
-  not  applicable 

A  single  value  in  the  D-column  applies  to  the  Initiator  role  of  a  system  as  well  as  to  the  Responder  role.  If  two 
values  are  specified  in  the  D-column  separated  by  a  space,  they  apply  to  the  Initiator  (I)  role  and  to  the  Responder 
(R)  role,  respectively. 


A.0.2  Conformance  requirement  of  Profiles 

The  Conformance  requirement  of  the  Implementation  Profiles  is  specified  in  the  'Profiles'  column/columns  in  clauses 
A.I  to  A.13.  The  following  convention  is  applied  for  this  purpose  : 

o    a  'PROFILES'  column  is  valid  for  all  Profiles  T1 .3,  T2.3,  A1 .3  and  Ml  .3 

0    if  different  conformance  requirements  apply  to  different  Profiles,  separate  columns  are  included  in  the  tables,  each 
bearing  the  corresponding  Profile  name  as  its  heading,  or  separate  tables  for  these  Profiles  are  used 
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0    a  single  value  in  these  columns  applies  to  the  Initiator  as  well  as  to  the  Responder  role  of  an  implementation 

0    if  two  values  are  specified  in  a  column  separated  by  a  space,  they  apply  to  the  Initiator  (I)  role  and  to  the  Re- 
sponder (R)  role,  respectively. 

For  the  conformance  requirements  of  the  NIST  FTAM  Phase  3  Profiles  the  following  abbreviations  are  used. 

mandatory;  m  : 

This  is  a  mandatory  or  optional  feature  in  the  base  standard.  It  shall  be  supported,  i.e.,  its  syntax  and  procedures 
shall  be  implemented  as  specified  in  the  base  standard  or  in  FTAM  Phase  3  by  all  implementations  claiming 
conformance  to  the  Profile. 


However,  it  is  not  a  requirement  that  the  feature  shall  be  used  in  all  instances  of  communication,  unless  mandated 
by  the  base  standard  or  stated  othenwise  in  FTAM  Phase  3. 

For  fully  supported  attributes,  this  implies  that  at  least  the  minimum  range  of  attribute  values,  as  defined  In  ISO 
8571-2,  shall  be  supported  unless  stated  otherwise  in  FTAM  Phase  3. 

Also  for  features  which  are  optional  in  the  base  standard,  conformant  implementations  shall  be  able  to  interwork 
with  other  implementations  not  supporting  this  feature. 

The  support  of  a  feature  can  be  conditional,  depending  on  the  support  of  a  class  of  features  to  which  it  belongs, 
e.g.,  an  attribute  in  an  attribute  group,  a  parameter  in  a  PDU,  a  PDU  in  a  functional  unit. 

optional;  o  : 

It  is  lett  to  the  implementation  as  to  whether  this  feature  is  implemented  or  not. 

If  an  attribute  group  with  a  support  level  of  'o'  is  chosen  to  be  supported,  then  all  the  attributes  in  this  group  that  are 
classified  as 'm'  shall  be  supported. 

The  support  for  PDUs  is  determined  by  the  negotiation  of  functional  units  when  the  connection  is  established. 

If  a  parameter  is  optionally  supported,  then  its  syntax  shall  be  implemented,  but  it  is  left  to  each  implementation 
whether  its  procedures  are  implemented  or  not. 

When  receiving  an  optional  parameter  which  is  not  subject  of  negotiation  and  is  not  supported  by  the  Receiver,  the 
Receiver  shall  at  least  inform  the  Sender  by  informative  diagnostic  and  interworking  shall  not  be  disrupted. 

conditional;  c  : 

This  feature  shall  be  supported  under  the  conditions  specified  in  FTAM  Phase  3.  If  these  conditions  are  not  met,  the 
feature  is  outside  the  scope  of  the  Profile. 

excluded;  x  : 

This  feature  is  excluded  from  the  Profile.  The  implementor's  answer  in  the  PICS  shall  always  be  'no', 
outside  the  scope;  i  : 

This  feature  is  outside  the  scope  of  the  Profile,  i.e.,  it  may  be  ignored,  and  will  therefore  not  be  subject  of  a  Profile 
conformance  test.  However  the  syntax  of  all  parameters  of  supported  PDUs  shall  be  implemented,  even  if  their 
procedures  are  not  (i.e.,  the  Receiver  shall  be  able  to  decode  the  PDU). 


not  applicable;  - : 

This  feature  is  not  defined  in  the  context  where  it  is  mentioned,  e.g.,  a  parameter  which  is  not  part  of  the  respective 
PDU.  The  occurrence  of  'not  applicable'  features  is  mainly  due  to  the  format  of  the  tables  in  the  Phase  3  Profiles 
Requirements  List. 
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A.I  (void) 
A.2  (void) 

Section  2:  General  ISO  8571  Detail 
A.3  ISO  8571  Protocol  versions 

FTAM  protocol  version  number{s)  version-1 


A.4  ISO  8571  Addenda 


ISO  8571-1 

ISO  8571-2 

ISO  8571-3 

ISO  8571-4 

ISO  8571-5 

A.5  Defect  report  numbers  and  amendments 


ISO  8571-1 

ISO  8571-2 

ISO  8571-3  ~ 

ISO  8571-4 

ISO  8571-5 

A.6  Global  statement  of  conformance 


Does  FTAM  Phase  3  conform  to  ISO  8571  ?  yeS 
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A.7  Initiator  /  Responder  capability 


ROLES 

D 

PRORLES 

I  R 

1 

Sender 

0 

o  o 

2 

Receiver 

0 

o  o 

NOTE  -  See  part  9  18.1 


A.8  Application  Context  Name  details 


1       ISO  8571-4  defines  a  value  for  a  simple  transfer  mechanism.  Other  values  are  not  defined  for  FTAM  Phase  3 
(see  part  9  5.9). 
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Section  3  :  Syntax  Detail 

A.9  Abstract  syntaxes 


Object  Descriptor 

Object  Identifier 

D 

T1.3 

T2.3 

A1.3 

M1.3 

FTAM  PCI 

(iso  standard  8571  abstract-syntax(2) 
ftam-pci(1) } 

m 

m 

m 

m 

m 

FTAM  FADU 

{iso  standard  8571  abstract-syntax(2) 
ftam-fadu(2) } 

0 

i 

m 

m 

i 

{joint-iso-ccitt  association-control(2) 
abstract-syntax(1 )  apdus(O)  version1(1) } 

m 

m 

m 

m 

m 

FTAM  unstructured 
text  abstract  syntax 

(iso  standard  8571  abstract-syntax(2) 
unstructured-text(3)  } 

0 

m 

m 

m 

FTAM  unstructured 
binary  abstract  syntax 

(iso  standard  8571  abstract-syntax(2) 
unstructured-binary(4)  ) 

0 

m 

m 

m 

- 

NBS  file  directory 
entry  abstract  syntax 

(iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-as2{2)  ) 

- 

c 

c 

c 

- 

NDo  aDSiraci 
syntax  ASl 

(iso  identifiGd-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-asl(l)  ) 

i 

c 

c 

NBS  random  access 

•  (iso  idGntifisd-organization  oiw(14)  ftamsig(5) 

c 

c 

node  name  abstract 
syntax 

abstract-syntax(2)  nbs-node-name(3) } 

see  clause  9 

NBS  random  binary 
access  file  abstract 
syntax 

(iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax(2)  nbs-random-binary(4) } 

i 

c 

c 

NBS  simple  text 
abstract  syntax 

(iso  identified-organization  oiw(14)  ttamsig(5) 
abstract-syntax(2)  nbs-simple-text(5) } 

i 

c 

c 

NOTES 

1  The  abstract  syntaxes  whicfi  are  supported  in  the  Implementation  Profile  Ml. 3  depend  on  the  T-or  A-Profile  in  conjunction  with 
which  Ml. 3  is  implemented. 

2  The  support  requirements  for  the  conditional  abstract  syntaxes  depend  on  the  constraint  sets  and  document  types  which  are 
implemented  (see  clause  A.  13). 

3  ISO  8571  requires  the  presence  of  the  transfer  syntax  derived  from  the  "Basic  Encoding  of  a  single  ASN.1  type  "(joint-iso-ccitt 
asnl  (1)  basic-encoding  (1))  encoding  rules  for  transfer  of  the  "FTAM  PCI"  and  the  "FTAM  FADU"  abstract  syntaxes.  Implementa- 
tion detail  of  this  transfer  syntax,  and  other  transfer  syntaxes  supported,  is  specified  in  the  PICS  of  ISO  8823. 
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Section  4  :  Virtual  Filestore  Detail 


A.10  Virtual  filestore 

This  clause  details  the  conformance  to  the  file  model,  file  attribute  support  and  to  file  structure  support. 
A. 10.1  File  model 


FILE  MODEL 

D 

PROFILES 
R 

Hierarchical 

0 

m 

Other  models  i 

m 

A.I  0.2  Attributes 

A.I  0.2.1   Attribute  groups 

ATTRIBUTE  GROUP  NAME 

D 

PROFILES 

Kernel 

m 

m 

Storage 

0 

0 

Security 

0 

o 

Private 

0 

1 

A.10. 2.2  Attribute  values 

KERNEL  GROUP 
(INITIATOR) 

D 

PROFILES 
1  full 

RANGE  OF  VALUES 

Filename 

f 

m 

see  A.  10.2.3 

Permitted  Actions 

f 

m 

Contents  Type 

f 

m 

see  A  12.7 

KERNEL  GROUP 
(RESPONDER) 

D 

PROFILES 
R  full 

RANGE  OF  VALUES 

Filename 

f 

m 

see  A. 10.2. 3 

Permitted  Actions 

f 

m 

Contents  Type 

f 

m 

see  A.  12.7 
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STORAGE  GROUP 
(INITIATOR) 

D 

PROFILES 
1  full 

RANGE  OF  VALUES 

7 

Storage  account 

f 

m 

8 

File  availability 

f 

m 

9 

Future  filesize 

f 

m 

see  part  9  1 7.9 

NOTE  -  An  initiator  shall  not  partially  support  attributes 

STORAGE  GROUP 
(RESPONDER) 

D 

PROFILES 
R  full               R  partial 

RANGE  OF  VALUES 

10 

Storage  account 

P 

o 

o 

11 

Date  and  time  of  creation 

P 

o 

o 

12 

Date  and  time  of  last  modification 

P 

o 

o 

13 

Date  and  time  of  last  read  access 

P 

o 

o 

14 

Date  and  time  of  last  attribute  modification 

P 

o 

o 

15 

Identity  of  creator 

P 

o 

o 

16 

Idenbty  of  last  modifier 

p 

o 

o 

17 

Identity  of  last  reader 

p 

o 

o 

18 

Identity  of  last  attribute  modifier 

p 

o 

o 

19 

File  availability 

P 

m 

X 

20 

Filesize 

P 

m 

X 

see  part  9  1 7.9 

21 

Future  filesize 

P 

o 

o 

see  part  9  1 7.9 

SECURITY  GROUP 
(INITIATOR) 

D 

PROFILES 
1  full 

RANGE  OF  VALUES 

22 

Access  control 

f 

m 

see  A. 12. 2 

23 

Legal  qualifications 

t 

m 

NOTE  -  An  initiator  shall  not  partially  support  attributes 

SECURITY  GROUP 
(RESPONDER) 

D 

PROFILES 
R  full             R  partial 

RANGE  OF  VALUES 

24 

Access  control 

P 

m 

X 

see  A. 12. 2,  part  9  9.2 

25 

Legal  qualifications 

P 

o 

o 
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See  part  9  9.1 


A.10.3  File  Structures 
A.I  0.3.1  Constraint  sets 


CONSTRAINT  SET  NAME 

D 

T1.3 

T2.3 

A1.3 

Ml. 3 

Unstructured 

0 

m 

m 

m 

- 

SequentiaJ  Fiat 

0 

i 

m 

m 

- 

Ordered  flat 

0 

1 

o 

o 

Ordered  flat  with  unique  names 

0 

1 

o 

o 

Ordered  hierarchical 

0 

i 

i 

1 

General  hierarchical 

0 

i 

i 

i 

General  hierarchical  with  unique  names 

0 

i 

1 

f 

NBS  ordered  flat 

1 

o 

o 

NBS  random  acxess 

i 

o 

o 

A.1 0.3.2  File  and  filestore  actions 
A.1 0.3.2.1   Filestore  Actions 

Support  for  filestore  actions  is  dependent  upon  the  functional  units  implemented  (see  A.12.4  and  A.12.5) 
A.1 0.3.2.2  File  Actions 


RESPONDER 

CONSTRAINT  SET 
unstructured 

ACTION 

D  T1.3 

Locate   

Read 

0  o 

Insert   

Replace 

0  o 

Extend 

0  0 

Erase 

0  i 
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CONSTRAINT  SET 

RESPONDER 

unstructured 

sequential 

ordered 

ordered  flat 

NBS 

NBS 

with  unique 

ordered 

random 

fiat 

flat 

names 

flat 

access 

ACTION 

D  T2.3 

D  T2.3 

n 
U 

To  O 

D 

T2.3 

D  T2.3 

D  T2.3 

Locate 

0  i 

0 

i 

0 

i 

i 

i 

Read 

0  o 

0  o 

0 

O 

0 

o 

o 

o 

Insert 

0  o 

0 

o 

0 

o 

o 

o 

Replace 

0  o 

0 

o 

0 

o 

o 

o 

Extend 

0  o 

0 

o 

0 

o 

Erase 

0  i 

0  i 

0 

i 

0 

1 

i 

1 

CONSTRAINT  SET 

RESPONDER 

unstructured 

sequential 
flat 

ordered 
flat 

ordered  flat 
with  unique 
names 

NBS 
ordered 
flat 

NBS 
random 
access 

ACTION 

D  A1.3 

D  A1.3 

D 

A1.3 

D 

A1.3 

D  A1.3 

D  A1.3 

13 

Locate 

0  o 

0 

o 

0 

o 

o 

o 

14 

Read 

0  o 

0  o 

0 

o 

0 

o 

o 

o 

15 

Insert 

0  o 

0 

o 

0 

o 

o 

o 

16 

Replace 

0  o 

0 

o 

0 

o 

o 

o 

17 

Extend 

0  o 

0 

o 

0 

o 

18 

Erase 

0  o 

0  o 

0 

o 

0 

o 

o 

o 

NOTE  -  File  actions  are  not  defined  in  Implementation  Profile  Ml. 3 
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RESPONDER 
ACCESS  CONTEXT 

US 
UA 
FS 


FL 


FA 


HN 


HA 


CONSTRAINT  SET 
unstructured 

D  T1.3 


o  m 


CONSTRAINT  SET 

RESPONDER 

unstructured  sequential 

ordered 

ordered  flat 

NBS 

NBS 

with  unique 

ordered 

random 

flat 

flat 

names 

flat 

access 

ACCESS  CONTEXT 

D     T2.3         D  T2.3 

D  T2.3 

D  T2.3 

D  T2.3 

D  T2.3 

US 

UA 

0       m          0  m 

0  m 

0  m 

m 

m 

FS 

FL 

FA 

  0  m 

0  m 

0  m 

m 

HN 

HA 

0  o 

0  o 

o 
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CONSTRAINT  SET 

unsir  uciur^u  sei^ucriiiai 

or  oer^ij 

no  J 

with  unique 

ordered 

random 

flat 

fiat 

names 

flat 

access 

ACCESS  CONTEXT 

D     A1.3         D  A1.3 

D  A1.3 

D  A1.3 

D  A1.3 

D  A1.3 

US 

UA 

0       m          0  m 

0  m 

0  m 

m 

m 

FS 

FL 

FA 

  0  m 

0  m 

0  m 

m 

HN 

HA 

0  o 

0  o 

o 

NOTE  -  The  supported  access  contexts  for  Impementation  Profile  M1.3  are  defined  in  the  T-  or  A-Profile  in  conjunction  with  which 
1^1.3  is  implemented. 


A.10.4  Additional  information 

( Void ) 


A.I 0.5  Override 

RESPONDER  OVERRIDE 

D  PROFILES 
R 

Create  failure 

0  m 

Select  old  file 

0  m 

Delete  and  recreate  with  old  attributes 

0  o 

Delete  and  create  with  new  attributes 

0  m 

NOTE  -  The  specification  of  the  role  of  initator  is  given  in  A,  12. 15. 
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Section  5  :  File  Protocol  Detail 


A.11  File  protocol 

See  part  9  clauses  5.1  •  5.3  and  17 

Subclauses  A. 11.2  to  A.1 1.24  specify  an  indication  of  which  PDUs  are  supported.  The  conformance  requirements 
for  PDUs  are  dependent  on  the  particular  functional  units  implemented.  PDUs  indicated  in  A.1 1.8  to  A. 11. 24  as 
conditional  shall  be  considered  as  mandatory  when  a  particular  functional  unit  is  implemented,  according  to  the 
following  table. 


1 

rUUS 

Clause 

Functional  Units 

Ker- 

Read 

Write 

Ac- 

LFM 

EFM 

Grou- 

Reco- 

Re- 

nel 

cess 

ping 

very 

start 

F-CREATE 

A.11. 8 

m 

F-DELETE 

A.1 1.9 

m 

F-READ-ATTRIB 

A.11. 10 

m 

F-CHANGE-ATTRIB 

A.11. 11 

m 

F-OPEN 

A.11. 12 

m 

m 

F-CLOSE 

A.11. 13 

1 1 1 

1 1 1 

F-BEGIN-GROUP 

A.11. 14 

m 

F-END-GROUP 

A.11. 15 

m 

F-RECOVER 

A.11. 16 

m 

F-LOCATE 

A.11. 17 

m 

F-ERASE 

A.11. 18 

m 

F-READ 

A.11. 19 

m 

F-WRITE 

A.1 1.20 

m 

F-DATA-END 

A.1 1.21 

m 

m 

F-TRANSFER-END 

A.1 1.22 

m 

m 

F-CANCEL 

A.1 1.23 

m 

m 

|f-restart 

A.1 1.24 

m 

NOTES 

1  In  order  to  keep  the  protocol  tables  compact  some  forward  references  have  been  introduced  to  clauses  which  expand  upon  the 
detail  of  field  support. 

2  The  FTAM  protocol  will  require  a  number  of  optional  lower  layer  services  to  be  available  (e.g.,  Application  Entity  Titles  in  ACSE). 
This  requirement  is  outside  the  scope  of  this  Profiles  Requirements  List. 
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( Void  ) 

A.11.2  FTAM  regime  establishment 


1 

D 

R 

PROFILES 
1  R 

1 

F-INITIAUZE  PDU 

m 

m 

m  m 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

State  result 

m 

m 

all  values  defined  in  ISO  8571 

3 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

4 

Protocol  version 

m 

m 

m  m 

see  Section  2 

5 

Implementation  information 

0 

0 

o  o 

see  A. 12.1 

6 

Presentation  context  management 

m 

m 

m  m 

see  note  1,  part  9  17.10 

7 

Service  class 

m 

m 

m  m 

see  A.  12.4 

8 

Functional  units 

m 

m 

m  m 

see  A.I 2.5 

9 

Attribute  groups 

m 

m 

m  m 

see  A.  10.2 

10 

Shared  ASE  information 

0 

0 

i  i 

see  part  9  5.8 

11 

FTAM  Quality  of  Service 

m 

m 

IT)  m 

see  A.  12.8 

12 

Contents  type  list 

0 

0 

m  m 

see  A.12.7.1,  part  9  18.4 

13 

Initiator  identity 

0 

m 

see  8.8,  part  9  16.1  and  18.4 

14 

Account 

0 

o 

see  8.8,  part  9  18.4 

15 

Filestore  password 

0 

see  A.12.11,  8.8,  part  9  16.1 

m 

16 

Diagnostic 

0 

m 

see  A.12.6,  8.5.2,  part  9  13 

17 

Checkpoint  window 

m 

m 

m  m 

see  note  2,  8.5.2 

NOTES 

1  The  values  available  for  the  presentation  context  management  field  depend  upon  the  functional  units  implemented  in  ISO  8823. 

2  Checkpoint  window  field  is  indicated  as  mandatory  in  accordance  with  ISO  8571-4.  The  field  is  defaulted  to  the  value  1. 
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D  PROFILES 

1    R                                      1  R 

F-TERMINATE  PDU                     mm  mm 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Shared  ASE  infomriation                 o    o                                          1  i 

see  part  9  5.8 

Charging                                 -    o                                         -  o 

see  A. 12. 10 

i  -  ; 

A,11.4  FTAM  regime  termination  (abrupt)  by  service  user 

D  PROFILES 

F-U-ABORT  PDU                        m  m 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Action  result                               m  m 

ail  values  defined  in  ISO  8571 

Diagnostic                               o  m 

see  A. 12.6,  part  9  13 

A.1 1.5  FTAM  regime  termination  (abrupt)  by  service  provider 

D  PROFILES 

F-P-ABORT  PDU                        m  m 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Action  result                               m  m 

all  values  defined  in  ISO  8571 

Diagnostic                               o  m 

see  A.12.6,  8.5.2,  part  9  13 
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A.11.6  File  selection 
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D 

PROFILES 

1  R 

1  R 

m  m 

in  tn 

RANGF  OF  VAL  UFS 

FIELD  NAME 

OR  REFERENCE 

State  result 

m 

m 

all  values  defined  in  ISO  8571 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

Attributes 

m  m 

m  m 

see  A. 10.2,  part  9  17.9 

Requested  acx;ess 

m 

m 

see  A. 12.16 

Access  passwords 

0 

m 

see  8.8,  part  9  16.2 

Concurrency  control 

0 

o 

see  A.12.13,  8.6.1 

Shared  ASE  information 

0  0 

1  i 

see  part  9  5.8 

Account 

0 

o 

see  8.8,  part  9  18.4 

Diagnostic 

o 

m 

see  A.12.6,  part  9  13 

A.1 1 .7  File  deselection 

D 

PROFILES 

1  R 

1  R 

F-DESELECT  PDU 

m  m 

m  m 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Action  result 

m 

-  m 

all  values  defined  in  ISO  8571 

Charging 

0 

-  o 

see  A  12.10 

Shared  ASE  information 

0  0 

1  1 

see  part  9  5.8 

Diagnostic 

0 

m 

see  A.12.6,  part  9  13 
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A.11.8  File  creation 
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[ 

I 
1 

) 

n 

PROFILES 

1  D 

1  n 

F-CREATE  PDU 

c 

c 

c  c 

see  A.1 1,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

State  result 

- 

m 

m 

all  values  defined  in  ISO  8571 

Action  result 

m 

m 

all  values  defined  in  ISO  8571 

Override 

m 

m 

see  A.12.15 

Initial  attributes 

m 

m 

m  m 

see  A. 10. 2,  part  9  10.2.2,17.9 

Create  password 

0 

m 

see  A. 12. 12,  8.7,  8.8, 
part  9  16.2 

Requested  access 

m 

m 

see  A.12.16 

Access  passwords 

0 

m 

see  8.8,  part  9  16.2 

Concurrency  control 

0 

o  - 

see  A.12.13,  8.6.1 

Shared  ASE  information 

0 

o 

i  i 

see  part  9  5.8 

Account 

0 

0 

see  8.8,  part  9  18.4 

Diagnostic 

0 

m 

see  A.  12.6,  part  9  13 

A.1 1.9  File  deletion 

I 

1 

) 

R 

PROFILES 
1  R 

F-DELETE  PDU 

c 

c 

c  c 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Action  result 

m 

-  m 

all  values  defined  in  ISO  8571 

Shared  ASE  information 

0 

0 

i  i 

Charging 

0 

-  o 

see  A.12.10 

Diagnostic 

0 

-  m 

see  A.  12.6,  part  9  13 
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A.11.10  Read  attributes 
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D 

1  R 

PRORLES 
1  R 

1 

F>READ-ATTRIB  PDU 

c  c 

c  c 

see  A.11,  A.  12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

Action  result 

-  m 

-  m 

all  values  defined  in  ISO  8571 

3 

Attribute  names 

m 

m  " 

4 

Attributes 

-  0 

-  m 

see  A,10.2,  part  9  17.9 

S 

Diagnostic 

-  0 

-  m 

see  A.I 2.6,  part  9  13 

A.11 .11  Change  attributes 

D 
1  R 

T1.3,  T2.3,  A1.3 

Ml. 3 
1  R 

1 

F^HANGE-ATTRIB 

c  c 

1 

m  tn 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

Action  result 

m 

i 

-  m 

all  values  defined  in  ISO  8571 

3 

Attributes 

m  0 

1 

m  m 

see  A.  10.2,  part  9  17.9 

4 

Diagnostic 

0 

i 

■  m 

see  A.I  2.6,  part  9  13 

A.1 1.1 2  File  open 

D 
1  R 

T1.3,  T2.3,  A1.3 
1  R 

Ml  .3 

F-OPEN  PDU 

c  c 

m  m 

i 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

State  result 

m 

m 

1 

all  values  defined  in  ISO  8571 

3 

Action  result 

m 

-  m 

i 

all  values  defined  in  ISO  8571 

4 

Processing  mode 

n 

m 

1 

see  A.  12.1 7 

5 

Contents  type 

m  m 

m  m 

I 

see  A.12.7.2 
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6 

Concuirency  control                    o    o                 o   o  i 

see  A.12.13,  8.6.1 

7 

Shared  ASE  information                o    o                  1     i  1 

see  part  9  5.8 

8 

Enable  FADU  locking                   m    -                 m   •  i 

■false'  for  T1.3  and  T2.3 

9 

Activity  identifier                         o    -                  o    -  1 

10 

Diagnostic                                 -    o                   -    m  i 

see  A.12.6,  part  9  13 

11 

Recovery  mode                         mm                  mm  1 

see  A.  12.18 

12 

Remove  contexts                       o    -                  1    =  i 

13 

Define  contexts                          o    -                   i   -  i 

14 

Presentation  action                     -    m                 -    m  I 

see  note 

^OTE  -  The  values  depend  upon  the  functional  units  implemented  in  ISO  8823. 

A.11.13  File  Close 

D             T1.3,  T2.3,  A1.3  M1.3 

1 

F-CLOSEPDU                           c                       m  1 

see  A.11.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Action  result                             m                      m  1 

all  values  defined  in  ISO  8571 

3 

Shared  ASE  infonmation                 o                       i  i 

see  part  9  5.8 

4 

Diagnostic                               o                      m  i 

see  A.12.6,  part  9  13 

A.11.14  Beginning  of  grouping 

D                 T1.3,  T2.3  A1.3 
S     R                 I     R                 1  R 

1 

F-BEGIN-GROUP  PDU                 c   c                   mm                  o  o 

see  A.11.  A.12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

2 

Threshold                                 m  -                    m    -                  m  - 

A.11.15  End  Of  grouping 

D                  T1 .3,  T2.3              A1 .3 

F-END-GROUP  PDU                    c                         m  o 

see  A.1 1,  A.12.5 

The  F-END-GROUP  PDU  carries  no  fields. 
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A.11.16  Regime  recovery 
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See  8.5 


n 
\  R 

1  1 .0,  1  A.O,  M1.<9 

1  R 

1 

F-RECOVER  PDU 

c  c 

c  c                     1                    see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

State  result 

-  m 

-    m                      1                    all  values  defined  in  ISO  8571 

3 

Action  result 

-  m 

-    m                     1                    all  values  defined  in  ISO  8571 

4 

Activity  identifier 

m 

m    -  1 

5 

Bulk  transfer  number 

m  - 

m    -                    1                    see  clause  9 

6 

Requested  access 

m  - 

m    -                    i  seeA.12.16 

7 

Access  passwords 

0  - 

m    -                    i                    see  8.8,  part  9  16.2 

S 

Contents  type 

-  m 

-    m                     1                    see  A.  12.7.2 

9 

Recovery  point 

m  m 

m    m  i 

10 

Diagnostic 

-  0 

-    m                      1                     see  A.1 2.6,  8.5.2,  part  9  13 

11 

Remove  contexts 

o  - 

i    •                      1                    see  notes 

12 

Define  contexts 

0 

1    -                      i                    see  notes 

13 

Presentation  action 

-  m 

-    m                     1                    see  notes 

NOTES 

1  The  values  available  for  the  presentation  action  field  depend  upon  the  functional  units  implemented  in  ISO  8823. 

2  Presentation  action  field  is  indicated  as  mandatory  in  accordance  with  ISO  8571-4.  The  field  is  defaulted  to  no  action. 

A.11.17  Locate  file  access  data  unit 

D 

1  R 

T1.3,  T2.3          A1.3  M1.3 
1  R 

1 

F-LOCATE  PDU 

c  c 

i                   mm!                see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

2 

Action  result 

-  m 

1                   -    m            i                  all  values  defined  in  ISO  8571 

3 

FADU  identity 

m  0 

1                  m    o           1                 see  part  9  17.9 

4 

FADU  lock 

0  - 

i                   o    -             i  seeA.12.14 

5 

Diagnostic 

0 

1                   -mi                  see  A.12.6,  part  9  13 
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A.11.18  Erase  file  access  data  unit 


December  1991  (Stable) 


1 

R 

T1  T  T9  "i 

A1  T 
M  1  .o 

1  R 

M  1  .o 

F-ERASE  PDU 

c 

c 

1 

m  m 

1 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Action  result 

m 

1 

m 

i 

all  values  defined  in  ISO  8571 

FADU  identity 

m 

1 

m 

i 

see  part  9  17.9 

Diagnostic 

0 

1 

-  m 

1 

see  A.  12.6,  part  9  13 

A.11.19  Read  bulk  data 

1 

D 

R 

T1.3,  T2.3 
1  R 

A1.3 
1  R 

Ml. 3 

F-READ  PDU 

c 

c  c 

m  m 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

FADU  identity 

m 

m  - 

m 

1 

see  part  9  1 7.9 

Access  context 

m 

m 

m 

i 

see  A.10.3.2.3 

FADU  lock 

0 

1 

0 

i 

A.11.20  Write  bulk  data 

1 

D 

R 

T1.3,  T2.3 
1  R 

A1.3 
1  R 

M1.3 

F-WRITE  PDU 

c 

c 

c  c 

m  m 

1 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

FADU  operation 

m 

m 

m 

i 

FADU  identity 

m 

m 

m 

see  part  9  17.9 

FADU  Lock 

0 

i 

o 

1 

Part  1C  -  FTAM  Phase  3 

A.1 1 .21  End  of  data  transfer 


December  1991  (Stable) 


D  T1.3,  T2.3,  A1.3  Ml. 3 

F-DATA-END  PDU  c  m  i  see  A.1 1 ,  A.12,5 

RANGE  OF  VALUES 

FIELD  NAME  OR  REFERENCE 

Action  result  mm  I  all  values  defined  in  ISO  8571 

Diagnostic  o  m  \  see  A.  12.6,  part  9  13 


A.11.22  End  of  transfer 


D 
1  R 

T1.3,  T2.3,  A1.3 
1  R 

M1.3 

F-TRANSFER-END  PDU 

c  c 

m  m 

1 

see  A  ll,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Action  result 

m 

-  m 

i 

all  values  defined  in  ISO  8571 

Shared  ASE  information 

0  0 

i  i 

1 

see  part  9  5.8 

Diagnostic 

.  -  0 

-  m 

i 

see  A.  12.6,  part  9  13 

A.11.23  Cancei  data  transfer 


See  part  9  clause  11 


D 

T1.3,  T2.3,  A1.3           Ml. 3 

F-CANCEL  PDU 

c 

m  i 

see  A.11,  A.12.5 

RANGE  OF  VALUES 

FIELD  NAME 

OR  REFERENCE 

Action  result 

m 

m  1 

all  values  defined  in  ISO  8571 

Shared  ASE  information 

0 

1  i 

see  part  9  5.8 

Diagnostic 

0 

m  i 

see  A.  12.6,  part  9  13 

A.1 1 .23.1  F-CANCEL  mapping 

See  part  9  clauses  11  and  17.10 
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A.1 1 .24  Restart  data  transfer 


D 

T1.3,  T2.3,  A1.3  SjI 

F-RESTART  PDU 

c 

c 

i                     see  A  ll,  A.  12.5 

FIELD  NAME 

RANGE  OF  VALUES 
OR  REFERENCE 

Checkpoint  identifier 

m 

m 

i 

A.1 2  Expanded  PDU  field  and  filestore  detail 

This  clause  identifies  further  PDU  field  and  filestore  detail  to  expand  on  that  given  in  A.10  and  A.1 1 . 
j  A.1 2.1  Implementation  Information  detail 

j  See  8,3,  part  9  5.6  and  12 


A.1 2.2  Access  control  detail 


See  7.3,  part  9  9.2 


Access  control  element  terms 

D 

PROFILES 

RANGE  OF  VALUES 

1 

Action  list 

m 

m 

2 

Concurrency  access 

0 

0 

see  A.  12.3.3 

3 

Identity 

0 

0 

see  A. 12.3.5,  A.12.3.6,  8.8 

4 

Passwords 

0 

0 

5 

Location 

0 

0 

A.1 2.3  Access  control  element  detail 
A.1 2.3.1  Action  list  detail  (initiator) 

( Void  ) 


A.1 2.3.2  Action  list  detail  (responder) 

( Void  ) 
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A.1 2.3.3  Concurrency  access  term 
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If  the  concurrency  access  term  is  supported  in  the  access  control  element  the  following  details  of  the  concurrency 
control  shall  be  available  with  each  action. 


T1.3 
Action 

not  required 
D  T1.3 

shared 
D 

T1.3 

exclusive 
D  T1.3 

no  access 
D  T1.3 

Read 

0 

o 

0 

o 

0 

o 

0  o 

Insert 

0 

1 

0 

1 

0 

1 

0  i 

Replace 

0 

o 

0 

o 

0 

o 

0  o 

Extend 

0 

o 

0 

o 

0 

o 

0  o 

Erase 

0 

1 

0 

i 

0 

1 

0  i 

Read  attributes 

0 

o 

0 

o 

0 

o 

0  o 

Change  attributes 

0 

1 

0 

i 

0 

i 

0  i 

Delete  file 

0 

0 

0 

o 

0 

o 

0  o 

T2.3 
Action 

not  required 
D  T2.3 

shared 
D 

T2.3 

exclusive 
D  T2.3 

no  access 
D  T2.3 

Read 

0 

o 

0 

o 

0 

o 

0  o 

Insert 

0 

0 

0 

0 

0 

o 

0  o 

Replace 

0 

o 

0 

o 

0 

0 

0  o 

Extend 

0 

o 

0 

o 

0 

o 

0  o 

Erase 

0 

i 

0 

1 

0 

i 

0  1 

Read  attributes 

0 

0 

0 

o 

0 

o 

0  0 

Change  attributes 

0 

i 

0 

i 

0 

1 

0  1 

Delete  file 

0 

o 

0 

o 

0 

0 

0  o 
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A1.3 
Action 

not  required 
D  A1.3 

shared 
D 

A1.3 

exclusive 
D  A1.3 

no  access 
D  A1.3 

17 

Read 

0 

o 

0 

o 

0 

0 

0 

o 

18 

insert 

0 

o 

0 

o 

0 

o 

0 

o 

19 

Replace 

0 

o 

o 

o 

0 

o 

0 

o 

20 

Extend 

0 

o 

0 

o 

0 

o 

0 

o 

21 

Erase 

0 

o 

0 

o 

0 

o 

0 

o 

22 

Read  attributes 

0 

0 

o 

o 

0 

o 

0 

0 

23 

Change  attributes 

0 

1 

0 

1 

0 

i 

0 

i 

24 

Delete  file 

0 

o 

0 

o 

0 

o 

0 

o 

M1.3              not  required 

Action  D 

Ml. 3 

shared 

D 

M1.3 

exclusive 
D 

no  access 
M1.3  D 

M1.3 

25 

Read 

0 

0 

Q 

1 

0 

j 

26 

Insert 

0 

0 

0 

i 

0 

1 

1 

27 

Replace 

0 

0 

0 

! 

0 

i 

28 

Extend 

0 

0 

b 

i 

0 

I 

29 

Erase  > 

-  t>o  - 

0 

0 

i 

0 

1 

30 

Read  attributes 

0 

o 

0 

o 

0 

o 

0 

o 

31 

Change  attributes 

0 

o 

0 

o 

0 

o 

0 

o 

32 

Delete  file 

0 

o 

0 

o 

0 

o 

0 

o 

A.1 2.3.4  Identity  term 

(  Void  ) 


A.1 2.3.5  Initiator  access  passwords 

If  the  passwords  term  of  the  access  control  element  is  implemented  the  following  values  shall  be  supported  for  the 
initiator  role. 


See  part  9  16.3 


Initiator  Access  Passwords 

D 

PROFILES 
1 

1 

OctetString 

0 

o 

2 

GraphicString 

0 

o 
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A.1 2.3.6  Responder  access  passwords 

If  the  passwords  term  of  the  access  control  element  is  implemented  the  following  values  shall  be  supported  for  the 
responder  role. 


See  part  9  16.3 


nespunuer  mccsss 
Passwords 

n 

T1  T 

OctetString 
GraphicString 

1  ^.o 

OctetString 
GraphicString 

A1  1 

M  1  .<J 

OctetString 
GraphicString 

Ml  1 
m  1  .o 

OctetString 
GraphicString 

Read-password 

0 

O 

o 

o 

1 

Insert-password 

0 

1 

o 

o 

1 

Replace-password 

0 

o 

o 

o 

i 

Extend-password 

0 

0 

o 

o 

i 

Erase-password 

0 

i 

i 

o 

1 

Read-attribute-pas  sword 

0 

o 

o 

o 

o 

Change-attribute-password 

0 

i 

1 

i 

0 

Delete-password 

0 

o 

o 

o 

o 

A.I  2.3.7  Location  term 

{  Void  ) 

A.1 2.3.7.1  Application  Entity  Titles  detail 

See  part  9  5.7 


A.1 2.3.8  Access  control  element  combinations 


Combinations 

D 

PROFILES 
R 

Identity 

Password 

Location 

0 

o 

Identity 

Password 

0 

o 

Identity 

Location 

0 

o 

Password 

Location 

0 

o 

Identity 

0 

o 

Password 

0 

o 

Location 

0 

o 

NOTE  -  Implementation  of  access  control  without  any  of  the  above  combinations  is  valid. 
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See  5.1,  8.1,  part  9  table  7 


D 

T1.3,T2.3 

A1.3 

M1.3  (T) 

M1.3  (A) 

Transfer  class 

0 

m 

1 

m 

1 

Access  class 

0 

1 

m 

1 

m 

Management  class 

0 

1 

m 

m 

Transfer  and  management  class 

0 

o 

1 

m 

1 

Unconstrained  class 

0 

1 

1 

1 

1 

NOTES 

1  The  initiator  is  only  permitted  to  specify  those  combinations  defined  in  ISO  8571-3 

2  The  notation  f^1.3(T)  indicates  Ml. 3  combined  with  a  Transfer  Profile  T1.3  or  T2.3.  Ml. 3(A)  means  M1.3  combined  with  the 
Access  Profile  A1.3. 


A.12.5  Functional  unit  field  detail 

See  8.1,  8.2,  part  9  table  7 


T1.3,  T2.3 

SERVICE  CLASSES 

Transfer 

Transfer  and  Management 

FUNCTIONAL  UNITS 

D 

T1.3,  T2.3 

D 

T1.3,  T2.3 

1 

Kernel 

m 

m 

m 

m 

2 

Read  (see  note  2) 

c 

0 

c 

o 

3 

Write  (see  note  2) 

c 

o 

c 

o 

4 

File  Access     

5 

Limited  File  Management 

0 

0 

m 

m 

6 

Enhanced 

File  Management 

0 

1 

0 

1 

7 

Grouping 

m 

m 

m 

m 

8 

FADU  Locking     

9 

Recovery 

0 

0 

0 

o 

10 

Restart 

0 

0 

0 

o 

NOTES 

1  The  recovery  and  the  restart  functional  units  are  only  available  at  the  internal  file  service  interface  and  should  only  be  explicitly 
referenced  in  the  protocol. 

2  The  c  indicates  that  either  or  both  of  the  read  and  write  functional  units  shall  be  implemented  in  the  particular  service  class. 
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A1.3 

SERVICE  CLASSES 

Access 

FUNCTIONAL  UNITS 

n 

M  1 

11 

Kernel 

m 

m 

12 

Read 

m 

m 

13 

Write 

m 

m 

14 

File  Access 

m 

m 

15 

Limited  File  Management 

0 

o 

16 

Enhanced 

File  Management 

0 

1 
1 

17 

Grouping 

0 

o 

18 

FADU  Locking 

0 

o 

see  8.6.2 

19 

Recovery 

0 

o 

20 

Restart 

0 

o 

See  8.1 

M1.3(T) 

SERVICE  CLASSES 

Transfer  Management 

Transfer  and  Management 

FUNCTIONAL  UNITS 

D      M1.3(T)  D 

M1.3{T) 

D 

M1.3(T) 

21 

Kernel 

m 

m 

m 

m 

22 

Read 

c 

o 

23 

Write 

c 

o 

24 

File  Access     

25 

Limited  File  Management 

0       m  m 

m 

m 

m 

26 

Enhanced 

File  Management 

0       m  0 

m 

0 

m 

27 

Grouping 

m 

m 

m 

m 

28 

FADU  Locking     

29 

Recovery 

0 

o 

30 

Restart 

0 

o 

NOTE  -  Ml. 3(1)  indicates  Ml. 3  in  conjunction  with  a  Transfer  Profile  11. 3  or  12. 3.  This  table  lists  only  the  additional  functionality 
as  defined  by  Ml. 3. 
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See  8.1 


Ml. 3(A) 


FUNCTIONAL  UNITS 


SERVICE  CLASSES 


Access 

D       Ml. 3(A) 


Management 
D      Ml. 3(A) 


Kernel 

m 

m 

Read 

Write   

File  Access   

Limited  File 
Management 

0 

m 

m 

m 

32 


Enhanced 

File  Management 


Grouping 


m 


m 


m 


38 


FADU  Locking 


Recovery 


Restart 


NOTE  -  Ml. 3(A)  indicates  Ml. 3  in  conjunction  with  the  Access  Profile  A1.3.  This  table  lists  only  the  additional  functionality  as 
defined  by  Ml. 3. 


A.12.6  Diagnostic  field  detail 


D 

T1.3,  T2.3,  A1.3 

Ml. 3 

Diagnostic  type 

m 

m 

m 

Error  identifier 

m 

m 

m 

Error  observer 

m 

m 

m 

Error  source 

m 

m 

m 

Suggested  delay 

0 

c 

1         see  8.5.2 

Further  details 

0 

m 

m 

For  values  of  the  'further  details'  term  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1 
(GO  and  G1)  character  sets  is  required  (see  part  9  clause  13). 
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A.12.7  Contents  type  detail 

A.I  2.7.1  Contents  type  list  parameter 


See  part  9  10.2.1 


D 

PROFILES 

Maximum  number  of  elements 

1  R 

document  type  specifications 
abstract  syntax  specifications 

0 

0 

o  m 
o  m 

A.I  2.7.2  Contents  type  parameter 

See  part  9  10.2.3 

D 

PROFILES 

REFERENCE 

document  type  specifications 

0 

m 

see  part  9  9.1 

abstract  syntax  /  constraint  set  pair 
specifications 

0 

i 

NOTE  -  The  detail  of  document  types  supported  is  contained  in  clause  A.  13. 


A.12.8  FTAM  Quality  of  service  details 


See  8.5.2 


A.12.9  Details  of  shared  ASE  information 

( Void  ) 


A.12.10  Details  of  charging 


See  part  9 

5.8  and  18.4 

Charging 

D 

PROFILES 
R 

Resource  identifier  term 

m 

m 

Cfiarging  unit  term 

m 

m 

Charging  value  term 

m 

m 
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Filestore  password  detail 

D 

PROFILES 

OctetString 

0 

o 

GraphicString 

0 

o 

A  12  12  Crpatp  na^^word  dptaii 

See  part  9  16.3 

Create  password  detail 

D 

PROFILES 

OctetString 

0 

o 

GraphicString 

0 

o 

A.1 2.1 3  Concurrency  control 

A. 12.13.1  Supported  values 

See  8.6.1 


T1.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

T1.3 

D 

T1.3 

D 

T1.3 

D 

T1.3 

Read 

0 

o 

0 

o 

0 

o 

0 

o 

insert 

0 

0 

i 

0 

i 

o 

Replace 

0 

o 

0 

o 

0 

o 

0 

o 

Extend 

0 

o 

0 

0 

0 

o 

0 

o 

Erase 

0 

1 

0 

i 

0 

i 

0 

i 

Read  attrib 

0 

o 

0 

o 

0 

o 

0 

0 

Change  attrib 

0 

i 

0 

i 

0 

i 

0 

1 

Delete  file 

0 

o 

0 

o 

0 

o 

0 

o 
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T2.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

T2.3 

D 

T2.3 

D 

T2.3 

D  T2.3 

9 

Read 

0 

o 

0 

o 

0 

o 

0  o 

10 

Insert 

0 

o 

0 

o 

0 

o 

o  o 

11 

Replace 

0 

o 

0 

o 

0 

o 

0  o 

12 

Extend 

0 

o 

0 

o 

0 

o 

0  o 

13 

Erase 

0 

1 

0 

1 

0 

1 

0  1 

14 

Read  attrib 

0 

o 

0 

o 

0 

o 

0  o 

25 

Change  attrib 

0 

1 

0 

i 

0 

i 

0  i 

16 

Delete  file 

0 

o 

0 

o 

0 

o 

0  o 

A1.3 

not  required 

shared 

exclusive 

no  access 

Action 

D 

A1.3 

D 

A1.3 

D 

A1.3 

D 

A1.3 

17 

Read 

0 

o 

0 

o 

0 

o 

0 

o 

18 

Insert 

0 

o 

0 

o 

0 

o 

0 

o 

19 

Replace 

0 

o 

0 

o 

0 

o 

0 

o 

20 

Extend 

0 

0 

0 

o 

0 

o 

0 

o 

21 

Erase 

0 

o 

0 

o 

0 

0 

0 

o 

22 

Read  attrib 

0 

o 

0 

o 

0 

o 

0 

o 

23 

Change  attrib 

0 

1 

0 

i 

0 

i 

0 

1 

24 

Delete  file 

0 

o 

0 

o 

0 

o 

0 

o 
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M1  t 

not  required 

shared 

exclusive 

no  access 

Action 

D  M1.3 

D 

M1.3 

D         Ml  .3 

D 

M1.3 

25 

Read 

0  1 

0 

1 

0  i 

o 

1 

26 

Insert 

0  1 

0 

1 

0  i 

0 

1 

27 

Replace 

0  i 

0 

i 



0  i 

0 

i 

28 

Extend 

0  i 

0 

i 

0  1 

0 

1 

29 

Erase 

0  1 

0 

i 

0  i 

0 

i 

30 

Read  attrib 

0  o 

0 

o 

0  o 

0 

o 

31 

Change  attrib 

0  o 

0 

o 

0  o 

0 

o 

32 

Delete  file 

0  o 

0 

o 

0  o 

0 

o 

A.12.13.2  Responder  Defauit  values 


See  8.6.1,  part  9  clause  14 


A.I  2.14  FADU  Locking 


A1,3 

not  required 

FADU  Locking  Support  Values 
shared 

exclusive 

no  access 

'■'  ' 

-  :                    !;V  • 

D 

A1.3 

D 

A1.3 

D 

A1.3 

D  A1.3 

1 

Read 

0 

o 

0 

o 

0 

o 

0  o 

2 

Insert 

0 

o 

0 

o 

0 

o 

0  o 

3 

Replace 

0 

o 

0 

0 

0 

o 

0  o 

4 

Extend 

0 

o 

0 

o 

0 

o 

0  o 

5 

Erase 

0 

o 

0 

o 

0 

o 

0  o 
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initiator  override 

0 

PROFILES 
1 

1 

Create  failure 

0 

o 

2 

Select  old  file 

0 

o 

3 

Delete  and  recreate  with  old  attributes 

0 

o 

4 

Delete  and  create  with  new  attributes 

0 

0 

NOTE  -  The  specification  of  the  role  of  responder  is  given  in  A.  10.5 


A.1 2.1 6  Requested  Access 


See  part  9  clause  15 


Action 

D 

T1.3  T2.3 

A1.3 

M1.3 

1 

Read 

0 

o  o 

o 

2 

Insert 

0 

i  o 

o 

3 

Replace 

0 

0  o 

o 

4 

Extend 

0 

o  o 

o 

5 

Erase 

0 

1  i 

o 

6 

Read  attribute 

0 

o  o 

o 

m 

7 

Change  attnbute 

0 

i  1 

i 

m 

8 

Delete  file 

0 

o  o 

o 

m 

A.12.17  Processing  mode 

Processing  mode 

D 

T1.3  T2.3 

A1.3 

Ml. 3 

1 

Read 

0 

o  o 

o 

2 

Insert 

0 

i  o 

o 

3 

Replace 

0 

o  o 

o 

4 

Extend 

0 

o  o 

o 

5 

Erase 

0 

i  1 

o 
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See  8.5.2 


Recovery  mode 

D 

T1.3,  T2.3,  A1.3 

M1.3 

1 

None 

0 

m 

i 

2 

At  start  of  transfer 

0 

m 

1 

3 

Any  active  checkpoint 

© 

o 

1 

it 
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Section  6  :  Document  Type  Detail 

A.13  Document  types 

See  7.1 

Conformance  to  document  types  is  given  at  two  levels.  The  following  table  indicates  which  document  types  have 
some  level  of  support.  The  detail  of  that  level  of  support  is  stated  in  the  following  tables. 


Entry  number 

FTAM-1  D 

T1.3 

T2.3  A1.3 

Ml. 3 

Object  descriptor 
Object  identifier 

ISO  FTAM  unstructured  text  o 
{iso  standard  8571  document-type(5)  unstnjctured-text(l)} 

m 

m  m 
see  A.  13,1 

i 

Entry  number 

FTAM-2  D 

T1.3 

T2.3  A1.3 

Ml. 3 

Object  descriptor 
Object  identifier 

ISO  FTAM  sequential  text  o 
{iso  standard  8571  document-type(5)  sequential-text(2)} 

i 

m  m 

see  A.  13.2 

i 

Entry  number 

FTAM -3  D 

T1.3 

T2.3  A1.3 

Ml. 3 

Object  descriptor 
Object  identifier 

ISO  FTAM  unstructured  binary  o 
{iso  standard  8571  document-type(5)  unstructured-binary(3)} 

m 

m  m 
see  A.  13.3 

1 

Entry  number 

FTAM-4  D 

T1„3 

T2.3  A1.3 

Ml. 3 

Object  descriptor 
Object  identifier 

ISO  FTAM  sequential  binary  o 
{iso  standard  8571  document-type(5)  sequential-binary(4)} 

i 

o  o 
see  A.  13.4 

i 

Entry  number 

NBS-6 

D          11 .3 

T2.3      A1.3   Ml. 3 

Object  descriptor 

NBS-6  FTAM  sequential  file 

i 

o           o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  sequential(6)  } 

see  A.I 3.5 

Entry  number 

NBS-7 

D 

T1.3 

T2.3       A1.3    Ml. 3 

Object  descriptor 
Object  identifier 

NBS-7  FTAM  random  access  file 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  random-file(7)  } 

i 

o          o  i 

see  A. 13.6 
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Entry  number 

NBS-8 

D 

T1.3 

T2.3       A1.3    Ml. 3 

Object  descriptor 
Object  identifier 

NBS-8  FTAM  indexed  file 

{iso  identified-organization  oiw(14)  ttamsig(5) 

document-type(5)  indexed-file(8)  ) 

I 

o           o  i 

see  A.13.7 

Entry  number 

NBS-9 

D 

T1.3      T2.3      A1.3    Ml. 3 

Object  descriptor 

NBS-9  FTAM  file  directory  file 

0           o           o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

1  ■ 

document-type(5)  file-directory(9)  } 

see  part  9  18.3 

Entry  number 

NBS-10 

D          T1.3       T2.3       A1.3    Ml. 3 

Object  descriptor 

NBS-10  FTAM  random  binary  access  file 

i            o           o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5) 

document-type(5)  random-binary(IO) } 

see  7.1 

Entry  number 

NBS-11 

D 

T1.3      T2.3      A1.3  M1.3 

Object  descriptor 

NBS-1 1  FTAM  indexed  file  with  unique  keys 

i           o          o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ttamsig(5) 

document-type(5)  indexed-file-with-unique-keys(11 )  ) 

see  A. 13. 8 

I 


Entry  number 

NBS-1 2 

D 

T1.3      T2.3       A1.3  M1.3 

Object  descriptor 

NBS-1 2  NBS  FTAM  simple  text  file 

i            o           o  i 

Object  identifier 

{iso  identified-organization  oiw(14)  ttamsig(5) 

document-type(5)  simple-text-file(12)  } 

see  A. 13. 9 
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Constraint  sets  and  FADU  identities  for  document  types 


For  the  constraint  set  /  FADU  identity  tables  tlie  following  notation  is  used: 


mandatory 


optional 
not  supported 
not  applicable 
excluded 


in  the  constraint  set  definition,  or  optional  in  the  constraint  set  definition  but  shall  be  implemented  by  implementations 

claiming  conformance  to  the  Profile.  The  support  of  the  FADU  identity  will  be  dependent  on  the  actions  which  have 

been  implemented. 

in  the  constraint  set  definition 

(outside  the  scope  of  this  ISP,  may  be  ignored) 

(not  defined  in  the  constraint  set  definition) 

(disallowed  in  the  document  type  definition  or  in  FTAM  Pheise  3) 


Implementation  Profile  T1.3. 


FADU  Identity 
Constraint  Set 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAM-1 

m 

FTAM-3 

m 

NBS-9 

m 
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T2.3  (see  7.2,  part  9  clause  10) 


Dec 


ember  1991  (Stable) 


FADU  Identity 
Constraint  Set 

Begin 

End 

First 

Last 

Current 

Next 

Previous 

Node 
Seq 

Node 
Number 

FTAM  unstructured 
constraint  set 

m 

FTAM'1 

m 

FTAM-3 

m 

NBS-9 

m 

FTAM  sequential  flat 
constraint  set 

o 

o 

o 

o 

o 

o 

o 

o 

FTAM-2 

m 

m 

i 

i 

i 

i 

i 

FTAM-4 

m 

m 

i 

i 

i 

i 

i 

1 

NBS-6 

m 

m 

X 

X 

i 

X 

X 

NBS-12 

m 

m 

X 

X 

X 

X 

X 

X 

FTAM  ordered  flat 
constraint  set 

o 

o 

o 

0 

o 

o 

o 

o 

o 

NBS-8 

m 

i 

i 

i 

i 

i 

i 

m 

i 

FTAM  ordered  flat  constr 
set  with  unique  names 

o 

o 

o 

o 

o 

o 

o 

NBS-11 

m 

i 

i 

i 

i 

m 

i 

NBS  ordered  flat 
constraint  set 

o 

0 

o 

o 

o 

o 

o 

o 

NBS-7 



m 

m 

m 

m 

i 

i 

m 

NBS  random  access 
constraint  set 

o 

o 

0 

o 

NBS-10 

m 

m 

m 

m 
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Implementation  Profile  A1.3  (see  part  9  clause  10) 


December  1991  (Stable) 


FADU  Identity 
Constraint  Set 

Begin 

End 

First 

l-ast 

Current 

Next 

Previous 

Node 

Node 

KJ 1 1  m  nor 

FTAM  unstructured 
constraint  set 

m 

FTAIW-1 

m 

FTAM-3 

m 

1  NBS-9 

m 

FTAM  sequential  flat 
constraint  set 

o 

o 

o 

o 

o 
i 

o 

o 

o 

FTAM-2 

m 

m 

m 

i 

m 

i 

i 

FTAM-4 

m 

m 

m 

i 

i 

m 

i 

i 

NBS-6 

m 

m 

m 

X 

X 

m 

X 

X 

NBS-12 

m 

m 

m 

X 

X 

m 

X 

X 

FTAM  ordered  flat 
constraint  set 

o 

o 

o 

0 

o 

o 

o 

o 

o 

NBS-8 

m 

m 

i 

i 

m 

m 

m 

m 

1 

j  FTAM  ordered  flat  constr 
set  with  unique  names 

o 

o 

o 

o 

o 

o 

o 

NBS-11 

m 

m 

m 

m 

m 

m 

i 

NBS  ordered  flat 
constraint  set 

0 

o 

o 

o 

o 

o 

o 

o 

NBS-7 

m 

m 

m 

m 

m 

m 

m 

m 

NBS  random  access 
constraint  set 

o 

0 

o 

o 

1  NBS-10 

m 

m 

m 

m 
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A.13.1   FTAM-1    (See  7.1) 


December  1991  (Stable) 


A.13.1.1  Universal  class  number  parameter  (See  part  9  10.1) 


D 

T1.3,  T2.3,  A1.3 

Universal  class  number  parameter  supported 

0 

m 

PrintableString  - 

Universal  class 

19 

0 

i 

TeletexString 

Universal  class 

20 

0 

1 

VideotexString  - 

Universal  class 

21 

0 

i 

lASString 

Universal  class 

22 

0 

m 

see  part  9  10.1.1-2 

GraphicString 

Universal  class 

25 

0 

m 

see  A. 13.1.3 

VisibleString 

Universal  class 

26 

0 

m 

GeneralString 

Universal  class 

27 

0 

m 

see  A.13.1.4 

A.I 3. 1.2  String  length  parameter  and  string  significance  parameter  combinations 


D 

T1.3,  T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

m 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

m 

Maximum  string  length  parameter  and 
not  significant  strings 

0 

m 

Unbounded  strings  and 
variable  length  strings 

0 

m 

Unbounded  strings  and 
not  significant  strings 

0 

m 

A.I  3.1 .3  G  sets  supported 

G  sets  which  are  supported  in  FTAM-1  GraphicString.  

For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  is  required, 
(see  part  9  10.1.1  and  10.1.3) 
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Part  10  -  FTAM  Phase  3 
A.13.1.4  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  in  FTAM-1  GeneralString 


December  1991  (Stable) 


For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  and  ISO  646  IRV  (CO)  control  character  set  is  required 
(see  part  9  10.1-3) 


A.I  3.2  FTAM-2       (see  7.1) 

A.1 3.2.1  Universal  class  number  parameter  (see  part  9  10.1) 

D                T2.3,  A1.3 

Universal  class  number  parameter  supported 

o  m 

PrintableString    -            Universal  class  19 

0  i 

TeletexString     -           Universal  class  20 

0  1 

VideotexString    -            Universal  class  21 

0  1 

lASString          -           Universal  class  22 

0  o 

see  part  9  10.1.1-2 

GraphicString     -           Universal  class  25 

0  m 

see  A.13.2.3 

VisibleString      -            Universal  class  26 

0  m 

GeneralString     -            Universal  class  27 

0  o 

see  A. 13. 2. 4 

A.I 3.2.2  String  length  parameter  and  string  significance  parameter  combinations 

D               T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0  1 

Maximum  string  length  parameter  and 
fixed  length  strings 

0  1 

Maximum  string  length  parameter  and 
not  significant  strings 

0  m 

Unbounded  strings  and 
variable  length  strings 

0  1 

Unbounded  strings  and 
not  significant  strings 

0  m 

55 


Part  10  -  FTAM  Phase  3 
A.I  3.2.3  G  sets  supported 


December  1991  (Stabl 


G  sets  which  are  supported  in  FTAM-2  GraphicString. 


For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  is  required, 
(see  part  9  10.1.1  and  10.1.3) 


A.1 3.2.4  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  in  FTAM-2  GeneralString 


For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  and  ISO  646  IRV  (CO)  control  character  set  is  required, 
(see  part  9  10.1.1-3) 


A.1 3.3  FTAM-3 


A.I 3.3.1  String  length  parameter  and  string  significance  parameter  combinations  (see  7.1) 


D          T1.3,  T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

i 

Maximum  string  length  parameter  and  . 
fixed  length  strings 

1 

Maximum  string  length  parameter  and 
not  significant  strings 

m 

Unbounded  strings  and 
variable  length  strings 

:                      -   -  Oi  . 

i 

Unbounded  strings  and 
not  significant  strings 

Q 

m 

I 
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A.13.4  FTAM-4  (see  7.1) 

A.1 3.4.1  String  length  parameter  and  string  significance  parameter  combinations 


D 

T2.3,  A1.3 

Maximum  string  length  parameter  and 
variable  length  strings 

0 

1 

Maximum  string  length  parameter  and 
fixed  length  strings 

0 

1 

Maximum  string  length  parameter  and 

0 

m 

not  significant  strings 

Unbounded  strings  and 
variable  length  strings 

0 

i 

Unbounded  strings  and 
not  significant  strings 

0 

m 
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Part  10  -  FTAM  Phase  3 
A.13.5  NBS-6 


December  1991  (Stable) 


See  part  9  tables  2,  3 

A.1 3.5.1  ParameterO 


D  T2.3,  A1.3 


ParameterO  supported 

m 

Universal-time 

Universal  class  23 

m 

Generalized-time 

Universal  class  24 

m 

boolean 

Universal  class  1 

m 

null 

Universal  class  5 

m 

A.I  3.5.2  Parameten 

(see  part  9  10.1) 

D               T2.3,  A1 .3 

Parameterl  supported 

m 

integer 

Universal  class  2 

m 

bit 

Universal  class  3 

m 

IA5 

Universal  class  22 

m 

GraphicString 

Universal  class  25 

m 

GeneralString 

Universal  class  27 

m 

OctetString 

Universal  class  4 

m 

A.I  3.5.3  Parameter2 


D 

T2.3,  A1.3 

Parameter2  supported 

o 
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Part  10  -  FTAM  Phase  3 
A.  13.6  NBS-7 


December  1991  (Stable) 


See  part  9  tables  2,  3 

A.I  3.6.1  ParameterO 


D 

T2.3,  A1.3 

ParameterO  supported 

m 

Univ6rsal-tim6 

Universal  class  23 

m 

Generalized-time 

Universal  class  24 

m 

boolean 

Universal  class  1 

m 

null 

Universal  class  5 

. 

m 

A.I  3.6.2  Parameterl 

(see  part  9  10.1) 

D 

T2.3,  A1.3 

Parameter  1  supported 

m 

integer 

Universal  class  2 

m 

bit 

Universal  class  3 

m 

IA5 

Universal  class  22 

m 

GraphicString 

Universal  class  25 

m 

GeneralString 

Universal  class  27 

m 

OctetString 

Universal  class  4 

m 

A.I  3.6.3  Parameter2 


D 

T2.3,  A1.3 

Parameter2  supported 

o 
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A.13.7  NBS-8 


December  1991  (Stable) 


See  part  9  tables  2,  3 

A.I  3.7.1  ParameterO 


Data  Types 

Key  Type 

D 

T2.3,  A1.3 

D       T2.3,  A1.3 

ParameterO  supported 

tn 

m 

universal -uiTie 

Universal  class  23 

m 

tn 

Generalized-lime 

Universal  class  24 

m 

m 

bcxjiean 

Universal  class  1 

m 

- 

null 

Universal  class  5 

m 

- 

A.I  3.7.2  Parameterl 

(see  part  9  10.1) 

Data  Types 

Key  Type 

D 

T2.3,  A1.3 

D       T2.3,  A1.3 

Parameter  1  supported 

m 

m 

integer 

Universal  class  2 

m 

m 

bit 

Universal  class  3 

m 

IA5 

Universal  class  22 

m 

m 

GraphicString 

Universal  class  25 

m 

m 

GeneralString 

Universal  class  27 

m 

m 

OctetString 

Universal  class  4 

m 

m 

A.I  3.7.3  Parameter2 

Data  Types 

Key  Type 

D 

T2.3,  A1.3 

D         T2.3,  A1.3 

Parameter2  supported 

o 

o 
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A.13.8  NBS-11 


December  1991  (Stable) 


See  part  9  tables  2,  3 

A.1 3.8.1  ParameterO 


Data  Types 

D      T2.3,  A1.3 

Key  Type 

D       T2.3,  A1.3 

ParameterO  supported 

m 

m 

Universai-time 

Universal  class  23 

m 

m 

Generalized-time 

-    "      Universal  class  24 

m 

m 

boolean 

Universal  class  1 

m 

null 

Universal  class  5 

nt 

- 

A  13  8  2  Parameterl 

(see  part  9  10.1) 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

D        T2  3  A1  3 

Parameterl  supported 

m 

m 

integer 

— =  

Universal  class  2 

m 

m 

bit 

Universal  class  3 

m 

IA5 

Universal  class  22 

rai 

m 

Graphics  thng 

Universal  class  25 

m 

m 

GeneralStnng 

Universal  class  27 

rn 

m 

OctetString 

Universal  class  4 

m 

m 

A.1 3.8.3  Parameter2 

Data  Types 

D        T2.3,  A1.3 

Key  Type 

D        T2.3,  A1.3 

ParameterZ  supported 

o 

o 
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A.13.9  NBS-12    (see  7.1) 

A.13.9.1   Universal  class  number  parameter  (see  part  9  10.1) 


D           T2.3,  A1.3 

1 

Universal  class  number  parameter  supported 

m 

2 

PrintableString 

Universal  class  19 

1 

3 

TeletexString 

Universal  class  20 

i 

4 

VideotexString 

Universal  class  21 

i 

5 

lASString 

Universal  class  22 

m 

6 

GraphicString 

Universal  class  25 

m 

see  A.  13.9.5 

7 

VisibleString 

Universal  class  26 

m 

8 

GeneralString 

Universal  class  27 

m 

see  A.  13.9.6 

A.1 3.9.2  String  length  parameter 


D 

T2.3,  A1.3 

Maximum  string  length  parameter  supported 

m 

A.1 3.9.3  String  significance  parameter 


D 

T2.3,  A1.3 

1 

String  significance  parameter  supported 

m 

see  7. 1  table  3(c) 

2 

Variable  length  strings  supported 

m 

3 

Fixed  length  strings  supported 

m 

A.1 3.9.4  Character  set  parameter 

D 

T2.3,  A1.3 

1 

Character  set  parameter  supported 

m 

see  7.1  table  3(c) 
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Part  10  -  FTAM  Phase  3 


December  1991  (Stable) 


A.1 3.9.5  G  sets  supported 

G  sets  which  are  supported  in  NBS-12  GraphicString.  

For  values  of  GraphicString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  G1) 
character  sets  is  required, 
(see  part  9  10.1.1  and  10.1.3) 


A.1 3.9.6  G  and  C  sets  supported 

G  and  C  sets  which  are  supported  in  NBS-12  GeneralString.  

For  values  of  GeneralString  only  the  support  of  character  strings  of  the  ISO  646  IRV  (GO)  and  ISO  8859-1  (GO  and  Gl) 
character  set  and  ISO  646  IRV  (CO)  control  character  sets  is  required, 
(see  part  9  10.1.1-3) 


-  END  OF  FTAM  PHASE  3  PROFILES  REQUIREMENTS  LIST  - 
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PART  10  -  FTAM  Phase  3 


December  1991  (Stable) 


Annex  B  (normative) 
Register  of  FTAM  Objects 


B.1  Introduction 

The  objects  defined  in  B.2.1  and  B.2.2  will  be  removed  fronn  this  document  after  ISO/IEC  ISP  10607-2 
and  ISO/IEC  ISP  10607-2/Amd.1  are  published.  During  the  period  between  publishing  the  ISP  and  the 
removal  of  the  definitions  from  this  document,  the  definitions  in  the  ISP  will  take  precedence  over  this 
document. 

When  the  object  definitions  are  removed,  clauses  B.2.1  and  B.2.2  will  be  changed  to  point  to  the  ISP. 
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Part  10  -  FTAM  Phase  3 

a2    Index  of  OIW  FTAM  Objects 

a>2J.    FTAM  Phase  2  Defined  Objects 


December  1991  (Stable) 


Object  Identifier  Prefix  :    nist-adhoc  ::=  {iso(1)  identified-organization(3)  icd(9999)  organization-code(l)} 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 
Registration 

Reference  to 
Definition 

MR«5-R  PTAM 

INOO  O  1    1  MIVl 

sequential  file 

\  1  llol  aUl  IVJLf 

document-type(5) 
sequential(6) } 

Withdrawn 
March  16.  '90 

Qtahvlo  An rQom ontc 
Olal/lc  MU 1  ool  1  loi  iLo 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-183 

part  9,  annex  A  clause  A.I 

IMDo-  / 

niDo"/  1  1  MM  ranuorn 
access  file 

|nisi~aunoc; 
document-type(5) 
random-filG(7) } 

Hoo  1 R  'OQ 

uec  lo,  oy 

Withdrawn 
March  1 6,  "90 

olaDIo  MQr66m6nio 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  9,  annex  A  clause  A.2 

MRc.o  FTAM 

CNDO'O  1   1  MM 

indexed  file 

\  1  lloL'dU  1  lUU 

document-type(5) 
indexed-file(8) } 

Fiar^  1 1:  'QQ 

Withdrawn 
March  16,  '90 

Vers.  4,  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  9.  annex  A  clause  A.3 

NRq.q  FTAM  file 
directory  file 

1  1  llol   Ck\J  1  l\J\^ 

document-type(5) 
file-directory(9) } 

Withdrawn 
March  1 6,  '90 

Ctahlo  Anroomontc 

wlClL^lC?  f^M  1  w C71 1  lt?l  1 19 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-183 

part  9,  annex  A  clause  A.4 

NBS  ordered  flat 
constraint  set 

f  nist-adhoc 
constraint-set(4) 
nbs-ordered-flat(l) } 

Dec  15  '89 

Withdrawn 
March  16,  '90 

Stable  Aareements 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-183 

part  9,  annex  B  clause  B.I 

NBS-AS1 

NBS  abstract 
syntax  AS1 

{nist-adhoc 
abstract-syntax(2) 
nbs-asl(l) } 

Dec  15,  '89 

Withdrawn 
March  16.  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NIST  SP  500-183 

part  9,  annex  C  clause  C.I 

NBS-AS2 

NBS  file  directory 
entry  abstract  syntax 

{nist-adhoc 
abstract-syntax(2) 
nbs-as2(2) } 

Dec  15,  '89 

Withdrawn 
March  16,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1 ,  December  '90 

NIST  SP  500-183 

part  9,  annex  C  clause  C.2 

AP-Title 

{nist-adhoc 
ftam-nil-ap-title(7) } 

Dec  15,  '89 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-183 

parts  12.1.1.1 
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Object  identifier  Prefix  :    nist-oiw-ftam  ::=  {iso(1)  identified-organization(3)  oiw(14)  ftamsig{5)} 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 
Registration 

Reference  to 
Definition 

NBS-6 

NBS-6  i=TAM 
sequential  file 

{nist-oiw-ftam 
document-type(5) 
sequential(6) } 

March  16.  '90 

Stable  Agreements 

Vers.  4.  Ed.  1,  December  '90 

NIST  SP  500-183 

part  9.  annex  A  clause  A.5 

NBS-7 

NBS-7  FTAM  random 
access  file 

{nist-oiw-ftam 
document-type(5) 
random-file(7) } 

March  1 6,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1.  December  '90 

NISTSP  500-183 

part  9.  annex  A  clause  A.6 

NBS-8 

NBS-8  FTAM 
indexed  file 

{nist-oiw-ftam 
document-type(5) 
indexed-file(8) } 

March  16.  "90 

Stable  Agreements 

Vers.  4.  Ed.  1.  December  '90 

NIST  SP  500-183 

part  9,  annex  A  clause  A.7 

NBS-9 

NBS-9  FTAM  file 
directory  file 

{nist-oiw-ftam 
document-type(5) 
file-director/i^Q) } 

March  1 6,  '90 

Stable  Agreements 

Vers.  4,  Ed.  1.  December  '90 

NIST  SP  500-183 

part  9,  annex  A  clause  A.8 

NBS  ordered  flat 
constraint  set 

{nist-oiw-ftam 
constraint-set(4) 
nbs-ordered-flat(l) } 

March  16,  '90 

Stable  Agreements 

Vers.  4.  Ed.  1 .  December  '90 

NIST  SP  500-183 

part  9.  annex  B  clause  B.2 

NBS-AS1 

NBS  abstract 
syntax  AS1 

{nist-oiw-ftam 
abstract-syntax(2) 
nbs-asl(l) } 

March  1 6.  '90 

Stable  Agreements 

Vers.  4.  Ed.  1,  December  '90 

NIST  SP  500-183 

part  9,  annex  C  clause  C.3 

NBS-AS2 

NBS  file  directory 
entry  abstract  syntax 

{nistHDiw-ftam 
abstract-syntax(2) 
nbs-as2(2) } 

March  16.  '90 

Stable  Agreements 

Vers.  4.  Ed.  1 .  December  '90 

NIST  SP  500-183 

part  9.  annex  C  clause  C.4 

i 
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B.2.2    FTAM  Phase  3  Deftned  Objects 


December  1991  (Stab] 


Object  Identifier  Prefix  :    nist-olw-ftam  >  iso(1)  identified-organization(3)  oiw(14)  ftamsig(5) 


Object 

Object  Descriptor 

Object  Identifier 

Date  of 
Registration 

Reference  to 
Definition 

NBS-10 

NBS-10  random 
binary  access  file 

{nist-oiw-ftam 
document-type(5) 
random-binary(IO) } 

Dec  15,  "89 

Stable  Agreements 

Vers.  4,  Ed.  1,  December  '90 

NISTSP  500-183 

part  10,  annex  C  clause  C.I 

NBS-11 

NBS-11  FTAM  indexed 
file  with  unique  i^eys 

{nist-oiw-ftam 
document-type(5) 
indexed-file-with-unique- 
keys(ll)} 

Dec  15.  '89 

Stable  Agreements 

Vers.  4.  Ed.  1.  December  '90 

NISTSP  500-183 

part  10.  annex  C  clause  C.2 

NBS-12 

NBS-12  FTAM 
simple  text  file 

{nist-oiw-ftam 

document-type(5) 

simple-text-file(12)} 

Dec  15.  '89 

Stable  Agreements 

Vers.  4,  Ed.  1.  December  '90 

NIST  SP  500-183 

part  10,  annex  C  clause  C.3 

NBS  Random  Access 

{nist-oiw-ftam 
constraint-set(4) 
nbs-random-access(2) } 

Dec  15.  "89 

Stable  Agreements 

Vers.  4.  Ed.  1 ,  December  '90 

NISTSP  500-183 

part  10.  annex  D  clause  D.1 

NBS-AS3 

NBS  random  access 
node  name  abstract 
syntax 
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Annex  C  (normative) 
Document  Types 

C.1      NBS-10  Random  Binary  Access  File 
C.1.1       Entry  Number:  NBS-10 
C.I  .2       Information  objects 
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Table  4  -  Information  objects  in  NBS-10 


document  type  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 
random-binary(IO)} 

"NBS-10  FTAM  random  binary  access  file" 

abstract  syntax  names: 

a)  name  of  asname! 

b)  name  of  asname2 

c)  name  of  asnameS 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2) 
nbs-random-binary(4) } 

"NBS  random  binary  access  file  abstract  syntax"  {iso  standard 
8571  abstract-syntax(2)  ftam-fadu(2)} 
"FTAM  FADU" 

{iso  identified-organization  oiw(14)  ftamsig(5) 

abstract-syntax(2)  nbs-node-name(3) } 

"NBS  random  access  node  name  abstract  syntax" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  encoding  of  a  single  ASN.1  type" 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  identified-organization  oiw(14)  ftamsig(5) 
constraint-set(4)  nbs-random-access(2)} 
"NBS  random  access  constraint  set" 

File  contents: 

Datatypel  ::=  OCTET  STRING 

Datatype2  ::=  Node-Name 
-The  type  to  be  used  for  Node-Name  is  defined  in  ISO  8571 -FADU 
-The  only  Choice  for  Node-Name  is  user-coded 

Datatypes  ::=  NBS-Node-Name 
-As  defined  by  the  NBS  Random  Access  Node-Name  Abstract  Syntax 

C.1.3       Scope  and  field  of  application 

This  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  by  FTAM. 
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C.1.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  Management 


C.1.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


C.1.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


C.1.7       Document  semantics 

The  document  consists  of  zero,  one,  or  more  File  Access  Data  Units.  Each  FADU  contains  precisely  one 
data  unit  which  consists  of  precisely  one  data  element.  The  data  element  is  made  up  of  one  octet.  The 
order  of  each  of  these  elements  is  significant.  The  semantics  of  the  data  elements  is  not  specified  by 
this  document  type. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as 
constrained  by  the  NBS  random  access  constraint  set.  The  definition  for  FTAM  hierarchical  file  model 
appears  in  8571-2. 

There  are  no  size  or  length  limitations  imposed  by  this  definition. 


C.1.8       Abstract  syntactic  Structure 

The  abstract  syntactic  structure  of  the  document  is  a  series  of  octets. 


C.1.9       Definition  Of  transfer 
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C.1 .9.1        Datatype  definition 

The  presentation  data  value  used  for  transfer  is  an  ASN.1  OCTET  STRING. 

Datatype2  is  used  to  specify  the  FADU-ldentity  of  "name-list"  in  the  FTAM  PDUs  specifying  FADU- 
Identity,  where  "name-list"  is  defined  as  a  SEQUENCE  of  EXTERNAL  The  EXTERNAL  is  defined  as 
Node-Name  in  the  FTAM  FADU  abstract  syntax.  The  use  of  Datatype2  is  defined  in  "NBS  random 
access  constraint  set." 
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Datatypes  specifies  the  "user-coded"  form  of  the  Node-Name  in  the  FTAM  FADU  abstract  syntax,  where 
"user-coded"  is  defined  as  an  EXTERNAL.  That  EXTERNAL  is  defined  by  Datatypes.  The  use  of 
Datatypes  is  defined  in  "NBS  random  access  constraint  set." 


C.1.9.2        Presentation  data  values 

The  document  is  transmitted  as  a  series  of  presentation  data  values.  Each  presentation  data  value  shall 
consist  of  the  "data"  from  one  or  more  FADUs  concatenated  together.  The  result  is  one  value  of  the 
ASN.1  data  type  OCTET  STRING.  The  "fadu-count"  field  supplied  in  the  Node-Name  specifies  the 
number  of  FADUs  to  transfer  during  a  Read  operation.  The  requested  FADUs  may  be  transferred  as  one 
or  more  presentation  data  values. 

All  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to  support  the  abstract 
syntax  name  "asnamel"  declared  in  table  4. 

NOTE  -  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be 
used,  when  the  above  permits  a  choice. 

Boundaries  between  P-DATA  primitives  and  between  presentation  data  values  are  chosen  locally  by  the 
sending  entity  at  the  time  of  transmission.  The  boundaries  are  not  preserved  when  the  file  is  stored  and 
they  carry  no  semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall 
accept  a  document  with  any  of  the  permitted  transfer  options. 


C.1.9.3        Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  is  the  same  as  the  sequence  of  Data  Units  within  the  file. 


C.1.10     Transfer  syntax  • 

An  implementation  supporting  these  document  types  shall  support  the  transfer  syntax  generation  rules 
named  in  table  4  for  all  presentation  data  values  transferred. 

Implementations  may  optionally  support  other  transfer  syntaxes. 


C.1.11     ASE  Specific  Specifications 


C.1.11.1  Simplification 

The  document  type  NBS-10  may  be  simplified  to  the  document  type  FTAM-S.  The  resultant  document 
contains  the  same  sequence  of  data  values  as  would  result  from  accessing  the  file  as  an  NBS-10  file. 
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C.I. 11 .2      The  READ  operation 

A  READ  operation  may  be  applied  to  a  range  of  FADUs  via  the  FADU-ldentlty  of  "NodeSeq."  Tlie 
"starting-fadu"  part  of  tlie  node  name  specifies  the  node  number  of  the  first  FADU;  the  "fadu-count" 
specifies  the  number  of  consecutive  FADUs  to  be  transferred. 

A  READ  operation  applied  to  a  range  of  FADUs  that  spans  beyond  the  end  of  file  is  valid.  All  available 
data  in  the  range  is  transferred.  An  informative  diagnostic  (5005)  is  returned  on  the  F-Data-End  request 
indicating  that  the  end  of  file  v/as  reached  and  a  portion  of  the  request  was  satisfied. 


C.1.11.3      The  REPLACE  operation 

When  the  REPLACE  operation  is  applied  to  the  root  FADU  of  an  NBS-10  document,  the  transferred  data 
shall  be  any  NBS-10  document. 

The  REPLACE  operation  applied  to  a  FADU-ldentity  of  "node  number"  is  used  to  replace  a  series  of 
FADUs,  starting  at  the  specified  position  in  the  file,  by  the  new  FADUs  being  transferred.  The  number  of 
replaced  FADUs  is  determined  by  the  number  of  transferred  FADUs. 

If  the  replacement  spans  beyond  the  end  of  the  existing  file,  then  the  additional  FADUs  are  inserted  at 
the  end  of  the  file. 


C.1 .1 1 .4      The  INSERT  operation 

When  the  INSERT  operation  is  applied  at  the  end  of  file,  the  transferred  data  shall  be  a  series  of  FADUs 
which  would  be  generated  by  reading  any  NBS-10  document  type  in  access  context  UA. 


C.2 


NBS-11  Indexed  File  With  Unique  Keys 


C.2.1 


Entry  Number:  NBS-11 


C.2.2 


Information  objects 
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Table  5  -  Information  objects  in  NBS-11 


document  name 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 

indexed-file-with-unique-keys(1 1 )} 

"NBS-1 1  FTAM  indexed  file  with  unique  keys" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract  syntax(2) 
nbs-as1(1)} 

"NBS  abstract  syntax  AS1" 

{iso  standard  8571  abstract-syntax(2)  ftam-fadu(2)} 

"FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  Encoding  of  a  single  ASN.1  type" 

parameter  syntax: 
PARAMETERS  ::=  SEQUENCE  { 

DataTypes, 

KeyType, 

KeyPosition  } 
DataTypes  ::=  SEQUENCE  OF  CHOICE  { 

ParameterO, 

Parameterl , 

Parameter2  } 
KeyType    ::=  CHOICE  { 

ParameterO, 

Parameterl , 

Parameter2  } 

-  ParameterO,  Parameterl ,  Parameter2,  as 

-  defined  for  the  document  types  NBS-6, 

-  NBS-7,  NBS-8 

KeyPosition::  =  INTEGER 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4) 
ordered-flat-unique-names(4)} 
"FTAM  ordered  flat  constraint  set  with  unique  names" 

file  contents: 
Datatypel  ::=  PrimType 

--  as  defined  in  NBS-AS1 

Datatype2  ::=  CHOICE  { 

Node-Descriptor-Data-Element, 

Enter-Subtree-Data-Elennent, 

Exit-Subtree-Data-Element  } 
Datatypes  ::=  Prim  Type  ~  as  defined  by  the  NBS  abstract  syntax  AS1 
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C.2.3       Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  for  transfer  and  access  using  FTAM. 
NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 


C.2.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  f\/lanagement 


C.2.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1. 


C.2.6  Abbreviations 

FTAM  File  Transfer,  Access  and  Management 


C.2.7       Document  semantics 

The  document  consists  of  zero,  one,  or  more  File  Access  Data  Units.  Each  FADU  consists  of  precisely 
one  data  unit  which  consists  of  zero,  one,  or  more  data  elements.  The  order  of  each  of  these  elements 
is  significant. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as 
constrained  by  the  FTAM  ordered  flat  constraint  set  with  unique  names  (see  table  5).  These  definitions 
appear  in  ISO  8571-2. 

The  following  additional  requirements  are  specified  for  the  use  of  the  ordered  flat  constraint  set  with 
unique  names: 

The  FADU  identity  'node  number'  Is  not  required  for  conformant  implementations; 

The  identities  'next'  and  'previous'  are  allowed  for  all  FADUs. 

Each  data  element  is  a  data  type  from  the  set  of  primitive  data  types  defined  In  part  9  Annex  C,  NBS 
abstract  syntax  ASl.  Each  data  unit  contains  the  same  data  element  types  In  the  same  order  as  all 
other  data  units.  These  types  and  their  respective  maximum  lengths  are  defined  by  the  <DataTypes> 
parameter. 
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For  Datatypel  and  Datatypes,  the  string-length  field  of  Parameterl  specifies  the  length  of  the  value  in 
octets  for  the  INTEGER,  BIT  STRING  and  OCTET  STRING  types.  For  character-type  data  elements,  the 
string-length  indicates  the  actual  number  of  characters  from  the  specified  character  set,  not  including 
any  escape  sequences  or  overhead  from  the  character  encoding. 

For  floating  point  numbers,  finite  form,  length-1  and  length-2  specify  the  length  in  bits  of  mantissa  and 
exponent,  respectively.  The  length-1  and  length-2  values  are  irrelevant  for  the  other  choices  of  floating 
point  numbers. 

Each  data  unit  in  the  file  has  a  key  associated  with  it,  which  is  the  user-coded  form  of  Node-Name.  The 
key  of  each  data  unit  is  of  the  same  data  type  as  the  key  of  all  other  data  units  in  the  file  and  is  a  single 
data  element  from  the  set  of  primitive  data  types  defined  in  part  9  Annex  C,  C.3  of  NIST  SP  500-183. 

The  type  and  length  of  the  key  are  defined  by  the  <KeyType>  parameter. 

The  primitive  data  types  and  minimum  size  ranges  of  each  unit  which  an  implementation  must  accept 
as  a  key  value  are  given  in  the  following  table  6. 


Table  6  -  Datatypes  for  keys 


Key  Type 

Minimum 

Order 

Range 

(octets) 

ASN.1  INTEGER 

(1-2) 

increasing  numeric  value 

ASN.1  lASString 

(1-16) 

lexical  order 

ASN.1  GraphicString        ASN.1  GeneralString 

(1-16) 

lexical  order 

ASN.1  OCTET  STRING 

(1-16) 

lexical  order 

ASN.1  GeneralizedTime 

(1-16) 

increasing  value 

ASN.1  UniversalTime 

increasing  time  value 

NBS-AS1  FloatingPointN  umber 

increasing  time  value 

increasing  numeric  value 

The  position  of  the  key  in  the  data  unit  is  specified  by  the  <  KeyPosition  >  parameter. 
KeyPosition  =  0  implies  the  key  is  not  part  of  the  data 
KeyPosition  >  0  specifies  the  actual  data  element  in  the  data  unit. 


C.2.8      Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the 
ASN.1  module  IS08571-FADU  in  ISO  8571,  in  which  each  of  the  file  access  data  units  has  the  abstract 
syntactic  structure  of  NBS-ASI  as  defined  by  the  parameters. 


76 


PART  10 


FTAM  Phase  3 


December  1991  (Stable) 


C.2.9 


Definition  of  transfer 


C.2.9.1 


Datatype  definitions 


The  file  consists  of  data  values  which  are  of 

a)  Datatypel  defined  in  table  5,  where  the  PrimType  In  the  datatype  is  given  by  the  NBS-ASI 
definition;  or 

b)  Datatype2  defined  in  table  5,  which  is  the  ASN.1  datatype  declared  as  "Data-Element"  in  the 
ASN.1  module  IS08571-FADU;  or 

c)  Datatypes,  defined  in  Table  5,  which  specifies  the  user-coded  form  of  the  Node-Name  in  the 
FTAM  FADU  abstract  syntax,  where  user-coded  is  defined  as  EXTERNAL 


C.2.9.2        Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  data  elements  from  the 
document.  All  values  are  transmitted  in  the  same  (but  any)  presentation  context  established  to 
support  the  abstract  syntax  name  "asnamel "  or 

b)  a  value  of  "Datatype2."  All  values  are  transmitted  in  the  same  (but  any)  presentation  context 
established  to  support  the  abstract  syntax  name  "asname2.";  or 

c)  a  value  of  "Datatypes"  carrying  a  Key.  All  values  are  transmitted  in  the  same  (but  any) 
presentation  context  established  to  support  the  abstract  syntax  name  "asnamel". 


1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used, 
where  the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  presentation  data  values  in  the  same  presentation  context,  and  boundaries  between 
P-DATA  primitives,  are  chosen  locally  by  the  sending  entity  at  the  time  of  transmission,  and  carry  no 
semantics  of  the  document  type.  Receivers  which  support  this  document  type  shall  accept  a  document 
with  any  of  the  permitted  transfer  options  (e.g.,  document  type  parameters  and  transfer  syntaxes). 


C.2.9.3        Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of 
types  a)  and  b)  is  the  same  as  the  sequence  of  data  elements  within  a  Data  Unit,  and  Data  Units  in  the 
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hierarchical  structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO 
8571-2. 


C.2.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules 
named  in  table  5  for  all  presentation  data  values  transferred.  Implementation  may  optionally  support 
other  named  transfer  syntaxes. 


C.2.1 1      ASE  Specific  Specifications 


C.2.11.1  Simplification 

This  simplification  loses  information. 

The  document  type  NBS-1 1  may  be  accessed  as  a  document  type  FTAM-3  (allowed  only  when  reading 
the  file)  by  specifying  document  type  FTAM-3  in  the  <  contents  type>  parameter  in  <F-OPEN  request  >, 
and  limiting  access  context  to  UA  on  F-READ. 

The  octet  representation  of  the  transferred  data  is  unpredictable.  It  will  usually  correspond  to  the  data 
values  as  stored  in  the  local  Real  Filestore  of  the  Responder. 

A  document  of  type  NBS-1 1  can  be  accessed  as  a  document  of  type  NBS-6  (allowed  only  when  reading 
the  file)  by  specifying  document  type  NBS-6  with  appropriate  data  type  parameters  in  the  <  contents 
type>  parameter  on  the  <F-OPEN  request>.  The  traversal  order  of  the  FADUs  must  be  maintained. 

NOTE  -  The  traversal  order  is  as  reading  the  file  as  NBS-1 1  in  key  order. 

A  document  of  type  NBS-1 1  may  be  accessed  as  a  document  of  type  NBS-8  (allowed  only  when  reading 
the  file)  by  specifying  document  type  NBS-8  in  the  <  contents  type>  parameter  in  the  <F-OPEN 
REQUEST>. 


C.2.11.2      Access  context  selection 

A  document  of  type  NBS-1 1  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the  FTAM 
ordered  flat  constraint  set  with  unique  names.  The  presentation  data  units  transferred  in  each  case  are 
those  derived  from  the  structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


C.2.1 1 .3      The  INSERT  operation 

When  the  <INSERT>  operation  is  applied,  the  transferred  material  shall  be  the  series  of  FADUs  which 
would  be  generated  by  reading  any  NBS-1 1  document  with  the  same  parameter  values  in  access 
context  FA. 
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A  transferred  FADU  whose  name  duplicates  that  of  an  already  existing  FADU  will  cause  the  <  INSERT > 
operation  to  fail.  The  failure  shall  be  signalled  by  issuing  an  F-CANCEL  Request  with  a  corresponding 
diagnostic. 

C.2.11.4      The  EXTEND  operation 

This  operation  is  excluded  for  use  with  this  document  type. 

C.2.11.5      The  REPLACE  operation 

When  the  <  REPLACE  >  operation  is  applied  with  FADU  Identity  'begin',  a  transferred  FADU  whose  name 
duplicates  that  of  a  previously  transferred  FADU  will  cause  the  <  REPLACE  >  operation  to  fail.  The 
failure  shall  be  signalled  by  issuing  an  F-CANCEL  Request  with  a  corresponding  diagnostic. 
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C.3     NBS-12  Simple  Text  File  Document  Type 
C.3.1       Entry  Number:  NBS-12 
C.3.2       Information  objects 


Table  7  -  Information  objects  in  NBS-12 


document  type  names 

{iso  identified-organization  oiw(14)  ftamsig(5)  document-type(5) 

simple-text-file(12)} 

"NBS-12  FTAM  simple  text  file" 

abstract  syntax  names: 

a)  name  for  asnamel 

b)  name  for  asname2 

{iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2) 

nbs-simple-text(5)} 

"NBS  simple  text  abstract  syntax" 

{iso  standard  8571  abstract-syntax(2)  ftam-fadu(2)} 

"FTAM  FADU" 

transfer  syntax  names: 

{joint-iso-ccitt  asnl  (1)  basic-encoding  (1)} 
"Basic  Encoding  of  a  single  ASN.1  type" 

Parameter  Syntax 

PARAMETERS  ::=  SEQUENCE  { 

universal-class-number  [0]  IMPLICIT  INTEGER, 
maximum-string-length  [1]  IMPLICIT  INTEGER, 
string-significance  [2]  IMPLICIT  INTEGER 

{variable  (0),  fixed  (1)}, 
character-set  [3]  IMPLICIT  OCTET  STRING  OPTIONAL  } 

file  model 

{iso  standard  8571  file-model(3)  hierarchical(l)} 
"FTAM  hierarchical  file  model" 

constraint  set 

{iso  standard  8571  constraint-set(4)  sequential  flat(2)} 
"FTAM  sequential  flat  constraint  set" 

File  contents 

Datatypel  ::=  NBS-Text 

-as  defined  in  the  NBS  Simple  Text 
-Abstract  Syntax  registration  entry 

Datatype2  ::  =  Node-Descriptor-Data-Eiement 
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C.3.3       Scope  and  field  of  application 

The  document  type  defines  the  contents  of  a  file  for  storage,  and  for  transfer  and  access  by  FTAM. 
NOTE  -  Storage  refers  to  apparent  storage  within  the  Virtual  Filestore. 

C.3.4  References 

ISO  8571,  Information  Processing  Systems  -  Open  Systems  Interconnection  -  File  Transfer, 
Access  and  Management 

ISO  8824,  Information  Processing  Systems  -  Open  Systems  Interconnection-Specification  of 
Abstract  Syntax  Notation  1  (ASN.  1). 

ISO  8825,  Information  Processing  Systems  -  Open  Systems  Interconnection-Basic  Encoding 
Rules  for  Abstract  Syntax  Notation  One  (ASN.  1). 

ISO  6429,  Information  Processing  -  ISO  7-bit  and  8-bit  coded  character  sets- Additional  control 
functions  for  character  imaging  devices. 

C.3.5  Definitions 

This  definition  makes  use  of  the  terms  data  element,  data  unit  and  file  access  data  unit  as  defined  in  ISO 
8571-1.  In  addition,  it  makes  use  of  the  terms  character  string,  graphics  character,  and  format  effector 
as  defined  in  document  type  registration  entry  "FTAM-2"  in  ISO  8571-2. 

C.3.6  Abbreviations 

FTAM    File  Transfer,  Access  and  Management 

C.3.7       Document  semantics 

This  document  consists  of  zero,  one,  or  more  File  Access  Data  Units.  Each  FADU  consists  of  precisely 
one  data  unit  which  consists  of  precisely  one  character  string.  The  order  of  each  of  these  elements  is 
significant.  The  semantics  of  the  character  strings  is  not  specified  by  this  document  type. 

The  document  structure  takes  any  of  the  forms  allowed  by  the  FTAM  hierarchical  file  model  as 
constrained  by  the  sequential  flat  constraint  set.  These  definitions  appear  in  ISO  8571-2.  As  additional 
constraints,  FADU  identity  will  be  limited  to  the  following  values: 

a)  "begin"  "and  "end"  when  using  the  Transfer  or  Transfer  and  Management  service  classes; 

b)  "begin,"  "end,"  "first,"  and  "next"  when  using  the  Access  sen/ice  class. 
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Each  character  string  consists  of  characters  from  the  character  set  defined  by  the  ASN.1  (ISO  8824) 
character  set  type  whose  universal  class  number  is  given  by  the  "universal-class-number"  parameter  and 
by  the  escape  sequences  contained  in  the  optional  "character-set"  parameter.  If  the  character  set  type 
allows  explicit  escape  sequences,  the  "character-set"  parameter,  if  present,  contains  escape  sequences 
which  designate  and  invoke  specific  character  sets.  If  the  "character-set"  parameter  is  not  present, 
character  sets  are  assumed  to  be  designated  and  invoked  as  specified  in  table  2  in  ISO  8825.  Character 
strings  shall  not  contain  escape  sequences. 

There  are  no  size  or  length  limitations  imposed  by  this  definition,  except  those  specified  here.  Each 
character  string  is  of  a  length  determined  by  the  number  of  characters  given  by  the  "maximum-string- 
length"  parameter. 

Y  NOTE  -  The  length  restriction  refers  to  the  number  of  characters  from  the  applicable  character  set,  not  to 
the  number  of  octets  in  the  encoding,  nor  to  the  line  length  in  any  rendition  of  the  document,  where  these 
are  different. 

The  exact  significance  of  the  character  strings  is  determined  by  the  "string-significance"  parameter.  If  its 
value  is  "variable,"  the  length  of  the  character  strings  is  less  than  or  equal  to  the  length  given.  If  the 
value  is  "fixed,"  the  length  of  each  character  string  is  exactly  equal  to  the  length  given. 

If  the  document  is  interpreted  on  a  character  imaging  device  (outside  the  scope  of  ISO  8571),  the 
interpretation  depends  on  the  character  set  in  use. 

a)  If  the  character  set  contains  format  effectors,  they  shall  be  interpreted  as  defined  in  ISO 
6429;  end  of  string  and  end  of  file  access  data  unit  are  given  no  formatting  significance,  and  do 
not  contribute  to  the  document  semantics; 

b)  If  the  character  set  does  not  contain  format  effectors,  the  end  of  each  character  string  is 
interpreted  as  implying  carriage  return  and  line  feed  formatting  actions  in  any  rendition.  The  end 
of  file  access  data  unit  is  given  no  formatting  significance  beyond  that  attached  to  the  end  of  the 
string  in  it. 


C.3.8       Abstract  syntactic  structure 

The  abstract  syntactic  structure  of  the  document  is  a  hierarchically  structured  file  as  defined  in  the 
ASN.1  modules  IS08571-FADU  and  ISO  8571 -CONTENTS  in  ISO  8571,  in  which  each  of  the  file  contents 
data  elements  has  the  abstract  syntactic  structure  of  "NBS-Text." 
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C.3.9       Definition  of  transfer 


C.3.9.1        Datatype  definitions 

The  file  consists  of  data  values  which  are  of  either 

a)  Datatypel  defined  in  table  7,  the  ASN.1  datatype  declared  as  "NBS-Text"  in  the  NBS  simple 
text  abstract  syntax  definition.  The  choice  in  "NBS-Text"  is  deternnined  by  the  universal-class- 
number  parameter;  or 

b)  Datatype2  defined  in  table  7,  the  ASN.1  datatype  declared  as  "Data-Element"  in  the  ASN.1 
module  ISO  8571 -FADU. 


C.3.9.2        Presentation  data  values 

The  document  is  transferred  as  a  series  of  presentation  data  values,  each  of  which  is  either 

a)  one  value  of  the  ASN.1  datatype  "Datatypel,"  carrying  one  of  the  character  strings  of  the 
document.  Each  character  shall  be  transmitted  using  one  of  the  character  sets  identified  by  the 
universal-class-number  parameter.  All  values  are  transmitted  in  the  same  (but  any)  presentation 
context  established  to  support  the  abstract  syntax  name  "asnamel"  declared  in  table  7;  or 

b)  one  value  of  the  ASN.1  datatype  "Datatype2."  All  values  are  transmitted  in  the  same  (but 
any)  presentation  context  established  to  support  the  abstract  syntax  name  "asname2"  declared 
in  table  7. 

NOTES 

1  Specific  carrier  standards  may  impose  additional  constraints  on  the  presentation  context  to  be  used, 
where  the  above  permits  a  choice. 

2  Any  document  type  defined  in  this  entry  either  makes  no  use  of  Datatype2,  or  starts  with  a  Datatype2 
transmission. 

Boundaries  between  P-DATA  primitives  are  chosen  locally  by  the  sending  entity  at  the  time  of 
transmission,  and  carry  no  semantics  of  the  document  type.  Receivers  which  support  this  document 
type  shall  accept  a  document  with  any  of  the  permitted  transfer  options. 
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C.3.9.3        Sequence  of  presentation  data  values 

The  sequence  of  presentation  data  values  of  type  a)  and  the  sequence  of  presentation  data  values  of 
types  a)  and  b)  is  the  same  as  the  sequence  of  character  strings  within  a  Data  Unit,  and  Data  Units  in 
the  hierarchical  structure,  when  flattened  according  to  the  definition  of  the  hierarchical  file  model  in  ISO 
8571-2. 


C.3.10     Transfer  syntax 

An  implementation  supporting  this  document  type  shall  support  the  transfer  syntax  generation  rules 
named  in  table  7  for  all  presentation  data  values  transferred. 


C.3.11     ASE  Specific  Specifications 


C.3.11.1       Simplification  and  relaxation 


c.3.11. 1.1         Simplification  to  FTAM- 1 

This  simplification  loses  information. 

The  document  type  NBS-12  may  be  accessed  as  a  document  type  FTAM-1.  The  resultant  document 
contains  the  same  sequence  of  data  values  as  would  result  from  accessing  the  structured  text  file  in 
access  context  UA.  That  is,  only  the  presentation  data  values  in  the  abstract  syntax  "asnamel"  are 
present.  If  the  "character-set"  parameter  was  present  before  the  simplification,  its  contents  will  be  added 
to  the  beginning  of  each  string. 

NOTE  -  The  boundary  between  file  access  data  units  remains  a  boundary  between  strings,  but  any  special 
significance  given  to  it  is  lost. 


C.3. 1 1 . 1 .2         Relaxation  to  FTAM-2 

The  document  type  NBS-12  may  be  relaxed  to  the  document  type  FTAM-2.  If  the  "character-set" 
parameter  was  present  before  the  relaxation,  its  contents  will  be  added  to  the  beginning  of  each  string. 


0.3. 1 1 . 1 .3         Character  set  relaxation 

This  operation  loses  explicit  information  in  the  document  type  identification. 
A  document  of  type  NBS-12  may  be  relaxed  to  a  different  document  of  type  NBS-12  with 
a  different  "universal-class-number"  parameter  value; 

a  different  "character-set"  parameter  value; 
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different  values  for  both  of  these  parameters; 

a  different  "unlversal-class-number"  parameter  value  and  no  "character-set"  parameter  value;  or 

no  "character-set"  parameter  value 

If  the  resultant  document  type  permits  all  characters  from  the  original  document  type.  If  this  relaxation 
involves  including  format  effectors  and  none  were  present  before  the  relaxation,  the  characters  "carriage 
return"  and  "line-feed"  shall  be  added  to  the  end  of  each  string. 

NOTE  -  If  the  characters  "carriage  return"  and  "line  feed"  are  not  part  of  the  format  effectors,  the  formatting 
action  may  be  represented  by  "newline,"  or  some  other  implementation  specific  choice  if  there  is  no 
representation  of  "newline"  defined. 


C.3. 11.1.4         String  length  relaxation 

This  operation  loses  explicit  information  in  the  document  type  identification. 

A  document  of  type  NBS-12  may  be  relaxed  to  another  document  type  NBS-12  with  a  larger  "maximum- 
string-length"  parameter. 


C.3.11.2      Access  context  selection 

A  document  of  type  NBS-12  may  be  accessed  in  any  one  of  the  access  contexts  defined  in  the 
sequential  fiat  constraint  set.  The  presentation  data  units  transferred  in  each  case  are  those  derived 
from  the  structuring  elements  defined  for  that  access  context  in  ISO  8571-2. 


C.3.1 1 .3      The  INSERT  operation 

When  the  INSERT  operation  is  applied  at  the  end  of  file,  the  transferred  material  shall  be  the  series  of 
FADUs  which  would  be  generated  by  reading  any  NBS-12  document  type  with  the  same  parameter 
values  in  access  context  FA. 


85 


PART  10  -  FTAM  Phase  3 


December  1991  (Stable) 


86 


PART  10  -  FTAM  Phase  3 


December  1991  (Stable) 


Annex  D  (normative) 
Constraint  Sets 

D.1      NBS  random  access  constraint  set 


Table  8  -  Basic  constraints  in  the  NBS  Random  Access  Constraint  Set 


Constraint  set  descriptor 

"NBS  random  access  constraint  set" 

Constraint  set  identifier 

{iso  identified-organization  oiw(14)  ftamsig(5)  constraint-set(4) 
nbs-random-access(2) } 

Node  names 

All  names  shall  be  of  the  same  type;  the  type  of  the  names 
and  an  ordering  of  the  names  shall  be  defined  when  reference 
is  made  to  the  constraint  set. 

File  access  actions 

Locate,  Read,  Insert,  Erase,  Replace 

Qualified  actions 

None 

Available  access  context 

UA 

Creation  state 

Root  node  without  an  associate  data  unit 

Location  after  open 

Root  node 

Beginning  of  file 

Root  node 

End  of  file 

No  node  selected 

Read  whole  file 

Read  in  access  context  UA  with  FADU-ldentity  of  "begin" 

Write  whole  file 

Transfer  a  series  of  leaf  FADUs  which  would  be  generated  by 
reading  the  whole  file  in  access  context  UA;  perform  the 
transfer  with  a  FADU  Identity  of  "end"  and  a  file  access  action 
of  "insert,"  or  with  a  FADU  Identity  of  "begin"  and  an  action  of 
"replace,"  or  with  an  FADU  identity  of  "node  number"  and  an 
action  of  "replace." 
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Table  9  -  Identity  constraints  in  the  NBS  Random  Access  Constraint  Set 


Action 

Begin                   [  End 

NodeSeq 

Node  number 

Locate 

leaf 

Read 

whole 

leaf 

Insert 

leaf 

Erase 

whole 

leaf 

Replace 

whole 

leaf 

NOTE  -  NodeSeq  =  A  sequence  of  Node-Names  with  a  single  member 

0.1.1       Field  of  application 

The  NBS  Random  Access  constraint  set  applies  to  files  which  are  structured  into  a  sequence  of 
individual  FADUs  and  to  which  access  may  be  made  randomly  by  NodeSeq.  The  structuring  of  the  file 
into  individual  FADUs  is  determined  by  the  Node-Name. 

D.1.2       Basic  constraints 

The  basic  constraints  in  the  NBS  Random  Access  constraint  set  are  given  in  table  8. 
D.1.3       Structural  constraints 

The  root  node  shall  not  have  an  associated  data  unit;  all  children  of  the  root  node  shall  be  leaf  nodes 
and  shall  have  an  associated  data  unit;  all  arcs  from  the  root  node  shall  be  of  length  one. 

D.I. 4       Action  constraints 

Insert:  the  insert  action  is  allowed  only  at  the  end  of  the  file,  with  FADU-ldentity  of  "end";  the  new  node 
is  inserted  following  all  existing  nodes  in  the  file.  The  location  following  the  insert  is  "end." 

Erase:  the  erase  action  is  allowed  at  the  root  node  to  empty  the  file,  with  FADU-ldentity  of  "begin."  The 
result  is  a  solitary  root  node  without  an  associated  data  unit.  Erase  with  the  FADU-ldentity  of  "node 
number"  means  truncation  of  the  file. 

Replace  whole  file:  the  FADU-ldentity  is  "begin"  and  the  complete  series  of  new  FADU  contents  is  sent. 

Replace  new  leaves:  the  FADU-ldentity  is  "node  number"  and  the  number  of  FADUs  being  replaced  is 
given  by  the  number  of  FADUs  sent. 
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D.I. 5       Identity  constraints 

The  FADU-ldentity  associated  with  the  file  action  shall  be  one  of  the  identities:  begin,  end,  Node 
Number  and  NodeSeq.  The  actions  with  which  these  identities  can  be  used  are  given  in  table  9. 
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Annex  E  (normative) 
Abstract  Syntaxes 


E.1      NBS  Node  Name  Abstract  Syntax 

Abstract  Syntax  Name 

{  iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-node-name(3)  } 

"NBS  random  access  node  name  abstract  syntax" 

This  is  an  abstract  syntax  for  the  user-coded  Node-Name  in  the  FTAM  FADU  abstract  syntax. 
NBS-AS3  DEFINITIONS::  = 
BEGIN 

NBS-Node-Name::=  SEQUENCE 

{         starting-fadu  [0]  IMPLICIT  INTEGER, 
fadu-count  [1]  IMPLICIT  INTEGER  } 
.     -a  "fadu-count"  of  0  specifies  the 
-range  of  FADUs 

.  -beginning  at  "starting-fadu"  and 
-ending  at  "end  of  file" 

END 

For  this  abstract  syntax  the  following  transfer  syntax  can  be  used. 

{  joint-iso-ccitt  asn1(1)  basic-encoding(l)  } 
"Basic  Encoding  of  a  single  ASN.1  type" 


90 


PART  10  -  FTAM  Phase  3 


December  1991  (Stable) 


E.2      NBS  Random  Binary  Access  File  Abstract  Syntax 

Abstract  Syntax  Name 

{  iso  identified-organization  oiw(14)  ftamsig(5)  abstract-syntax(2)  nbs-random-binary(4)  } 
"NBS  random  binary  access  file  abstract  syntax" 

This  is  an  abstract  syntax  for  the  transfer  of  the  file  contents  for  NBS  random  binary  files. 
NBS-AS4  DEFINITIONS::  = 
BEGIN 

NBS-Random  Binary  ::=  OCTET  STRING 
--contains  one  or  more  presentation  data  values 
-concatenated  together. 
-Each  presentation  data  value  is  defined  as 
-Datatypel  in  table  4. 

END 

For  this  abstract  syntax,  the  following  transfer  syntax  can  be  used: 

{  joint-iso-ccitt  asn1(1)  basic-encoding(l)  } 
"Basic  Encoding  of  a  single  ASN.1  type" 
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E.3      NBS  Simple  Text  Abstract  Syntax 

Abstract  Syntax  Name 

{iso  identified-organization  oiw(14)  ftamsig(5) 
abstract-syntax (2)  nbs-simple-text(5)  } 

"NBS  simple  text  abstract  syntax" 

NBS-AS5  DEFINITIONS::  = 

BEGIN 

NBS-Text::=  CHOICE  { 

IA5String,--Unlversal  Class  22 
GraphlcString,  --Universal  Class  25 
VisibleString,  -Universal  Class  26 
GeneralString  -Universal  Class  27  } 

END 

For  this  abstract  syntax,  the  following  transfer  syntax  can  be  used: 

{joint-iso-ccitt  asn1(1)  basic-encoding(l)} 
"Basic  encoding  of  a  single  ASN.1  type" 
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Annex  F  (normative) 

Delta  Protocol  Implementation  Conformance  Statement  (PICS)  Pro 
forma 

(Refer  to  the  Working  Implementation  Agreements.) 
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Annex  G  (normative) 
Amendments  and  Corrigenda 

Implementations  conforming  to  these  agreements  shall  implement  the  defect  report  solutions  contained 
in  the  following: 

FTAM: 


a) 

ISO  8571-1 /Cor.  1 

1990; 

b) 

ISO  8571-2/Cor.1 

1990; 

c) 

ISO  8571-3/Cor.1 

1990; 

d) 

ISO  8571-4/Cor.1 

:1990; 

e) 

ISO  8571-3/Cor.2 

f)  ISO  8571-4/Cor.2. 

Editor's  Note  -  The  corrigenda  ISO  8571-3/Cor.2,  and  ISO  8571-4/Cor.2  is  to  be  published.  Until  it  is 
available,  the  solutions  can  be  found  in  the  documents  ISO/IEC  JTC/SC21  N5234  and  ISO/IEC 
JTC1/SC21  N  5235. 
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Foreword 

This  part  of  the  Stable  Implementation  Agreements  was  prepared  by  the  Directory  Sen/ices  Special  Interest 
Group  (DSSIG)of  the  Open  systems  Interconnection  Implementors'  Workshop  (OIW).  See  Procedures 
Manual  for  Workshop  charter. 

Text  in  this  part  has  been  approved  by  the  Plenary  of  the  above  mentioned  Workshop.  This  part  replaces 
the  previously  existing  chapter  on  Directory  Services  Protocol.  There  are  some  minor  technical  changes  from 
this  text  as  previously  given. 

Future  changes  and  additions  to  this  version  of  these  Implementor  Agreements  will  be  published  as  change 
pages.  Deleted  and  replaced  text  will  be  shown  as  strikeout.  New  and  replacement  text  will  be  shown  as 
shaded. 
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0  Introduction 


This  is  an  Implementation  Agreement  developed  by  the  Implementor's  Workshop  sponsored  by  the  National 
Institute  of  Standards  and  Technology  to  promote  the  useful  exchange  of  data  between  devices 
manufactured  by  different  vendors.  This  agreement  is  based  on  and  employs  protocols  developed  in  accord 
vj\th  the  OSI  Reference  Model.  While  this  agreement  introduces  no  new  protocols,  it  eliminates  ambiguities 
in  interpretations. 

This  is  an  Implementation  Agreement  for  the  OSI  Directory  based  on  the  ISO  and  CCITT  documents  cited 
in  clause  2  of  this  part(hereafter  referenced  as  Directory  Documents).  This  agreement  is  aligned  with  the 
UNOFFICIAL  'FINAL'  version  of  the  X.500  Series  of  Recommendations,  December  1988.  Where  technical 
differences  between  the  ISO  and  CCITT  versions  of  these  documents  exist  (e.g..  Transport  Requirements) 
the  ISO  versions  are  given  precedence.  Figure  1  displays  the  structure  of  this  Implementation  Agreement. 
References  to  corresponding  CCITT  documents  are  included  for  information. 


Directory  Access  Protocol 
(DAP) 


Directory  System  Protocol 
(DSP) 


Remote  Operations  Services  and  Protocols 
(CCITT  X.219  and  X.229/ISO  9072/1  and  9072/2) 


Association  Control  Services  and  Protocols 
(CCITT  X.217  and  X.227/ISO  8649  and  8650) 


Figure  1  -  Structure  of  this  implementation  agreement 


The  Directory  User  Agents  (DUAs)  and  Directory  System  Agents  (DSAs)  provide  access  to  The  Directory 
on  behalf  of  humans  and  applications  such  as  Message  Handling  and  File  Transfer,  Access,  and 
Management.  See  clause  1  for  more  information  on  the  model  used  in  the  Directory. 


This  document  covers  both  the  Directory  Access  Protocol  (DAP)  and  the  Directory  System  Protocol  (DSP) 
defined  in  the  Directory  Documents.  A  good  working  knowledge  of  the  Directory  Documents  is  assumed 
by  this  chapter.  All  terminology  and  abbreviations  used  but  not  defined  in  this  text  may  be  found  in  those 
documents. 
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1  Scope 

Centralized  and  distributed  directories  can  both  be  accommodated  in  this  Agreement  by  the  appropriate 
choice  of  protocols  and  pragmatic  constraints  from  those  specified.  Figure  2  illustrates  a  centralized 
directory  and  figure  3  illustrates  a  distributed  directory. 

This  agreement  does  not  cover  interaction  between  co-located  entities,  such  as  a  co-resident  DUA  and  DSA. 
It  also  does  not  specify  the  interface  between  a  user  (person  or  application)  and  a  DUA. Bilateral  agreements 
between  a  DUA  and  DSA  or  DSA  and  DSA  may  be  implemented  in  addition  to  the  requirements  stated  in 
this  document.  Conformance  to  this  agreement  requires  the  ability  to  interact  without  the  use  of  bilateral 
agreements  other  than  those  required  in  the  Directory  Documents. 

The  logical  structure  of  the  Directory  Information  Base  (DIB)  is  described  in  the  Directory  Documents.  The 
manner  in  which  a  local  portion  of  the  DIB  is  organized  and  accessed  by  its  DSA  is  not  in  the  scope  of  this 
agreement. 


USER  <  >         DUA  < 


USER  <  >         DUA  <- 


The  Directory 


DSA 


Figyre  2  -  Centralized  directory  model 
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Figure  3  -  Distributed  directory  model 


References 


2.1      Normative  References 
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Models. 
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Selected  Object  Classes. 

ISO/IEC  9594-8:1 990(E), Information  Technology  -  Open  Systems  Interconnection  -  The  Directory  -  Part  8: 
Authentication  Framework. 

CCITT  Recommendation  X.500:1988,The  Directory  -  Overview  of  concepts,  Models  and  Services. 

CCITT  Recommendation  X.501:1988,The  Directory  -  Models. 

CCITT  Recommendation  X.509:1988,The  Directory  -  Authentication  Framework. 

CCITT  Recommendation  X.511:1988,The  Directory  -  Abstract  Service  Definition. 

CCITT  Recommendation  X.518:1988,The  Directory  -  Procedures  for  Distributed  Operations. 

CCITT  Recommendation  X.519:1988,The  Directory  -  Protocol  Specifications. 

CCITT  Recommendation  X.520:1988,The  Directory  -  Selected  Attribute  Types. 

CCITT  Recommendation  X.521:1988,The  Directory  -  Selected  Object  Classes. 

The  following  references  represent  a  forthcoming  edition  of  the  OSI  Directory  standard.  Alignment  to  that 
edition  within  these  agreements  is  only  where  explicitly  indicated  within  particular  subclauses. 

ISO/IEC  9594-1  /  DAM-1.2  for  Replication,  Schema,  and  Access  Control. 

ISO/IEC  9594-2  /  DAM-1.3  for  Access  Control. 

ISO/IEC  9594-2  /  DAM-2.2  for  Schema. 

ISO/IEC  9594-2  /  DAM-3.2  for  Replication. 

ISO/IEC  9594-3  /  DAM-1.3  for  Access  Control. 

ISO/IEC  9594-3  /  DAM-2.2  for  Replication,  Schema,  and  Enhanced  Search. 
ISO/IEC  9594-4  /  DAM-1 .3  for  Access  Control. 

ISO/IEC  9594-4  /  DAM-2.2  for  Replication,  Schema,  and  Enhanced  Search. 
ISO/IEC  9594-5  /  DAM-1 .2  for  Replication. 
ISO/IEC  9594-6  /  DAM-1.2  for  Schema. 
ISO/IEC  9594-7  /  DAM-1.2  for  Schema. 
ISO/IEC  9594-9  /  CD  for  Replication. 
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2.2      Informative  References 


Directory  Implementors'  Guide,  Version  5,  July  1991. 


3  Status 

This  version  was  completed  in  December  1990. 


4     Use  of  the  Directory 

Given  the  rapid  multiplication  and  expansion  of  OSI  applications,  telecommunication  systems  and  sen/ices, 
there  is  growing  need  for  users  of  OSI  applications,  as  well  as  the  applications  themselves,  to  communicate 
with  each  other.  In  order  to  facilitate  their  communications,  a  Directory  protocol,  as  referenced  in  these 
agreements,  has  been  tailored  to  meet  their  respective  needs. 

In  one  instance,  The  Directory  will  be  used  as  a  service  to  provide  humans,  in  an  on-line  fashion,  rapid  and 
easy  retrieval  of  information  useful  for  determining  what  telecommunications  services  are  available,  and/or 
how  to  access,  and  address  their  correspondents.  Further,  service  providers  offering  such  a  Public  Directory 
may  also  use  this  service  internally  with  other  various  telecommunications  services  (e.g.,  MHS)  for  the 
proper  addressing  of  calls  or  messages.  Likewise,  this  does  not  preclude  the  usage  of  these  agreements 
to  similarly  generate  a  privately  operated  Directory  that  supports  both  human  and  application  information 
exchanges. 

In  another  instance.  The  Directory,  will  be  used  as  a  service  by  computer  applications  without  direct  human 
involvement.  One  important  service  is  to  provide  Presentation  Address  resolution  for  named  objects,  on 
behalf  of  OSI  applications.  The  Directory  may  be  used  by  applications  to  search  for  objects  (i.e.,  Application 
Entities),  without  direct  human  involvement,  by  the  use  of  the  "search"  or  "list"  operations. 

To  support  the  many  possible  usages.  The  Directory  is  a  general  purpose  system.  It  is  capable  of  storing 
data  of  many  different  forms  as  attributes  within  entries,  and  is  also  capable  of  supporting  simple  or  complex 
hierarchical  structures,  with  variations  in  structure  possibly  occurring  between  one  part  of  The  Directory  and 
another. 

Compliant  DSA  implementations  should  safeguard  this  generality,  where  possible,  by  placing  the  minimum 
of  restrictions  in  "hard-wired"  form. 
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5  Directory  ASEs  and  Application  Contexts 

This  clause  highlights  the  ASEs  (Application  Service  Elements)  and  Application  Contexts  defined  in  the 
Directory  Documents  and  of  concern  in  these  Agreements.  The  functionality  of  the  Directory  AEs  (DUAs  and 
DSAs)  is  defined  by  a  set  of  ASEs,  each  Directory  ASE  specifying  a  set  of  Directory  operations. 

The  interaction  between  these  AEs  is  described  in  terms  of  their  use  of  ASEs.  This  specific  combination  of 
a  set  of  ASEs  and  the  rules  for  their  usage  defines  an  application  context. 

The  following  ASEs  are  described  in  the  Directory  Documents: 

a)  Read  ASE; 

b)  Chained  Read  ASE; 

c)  Search  ASE; 

d)  Chained  Search  ASE; 
^         e)  Modify  ASE; 

f)  Chained  Modify  ASE. 
ROSE  and  ACSE  also  form  part  of  the  Directory  Application  Contexts. 
The  following  Application  Contexts  are  described  in  the  Directory  Document: 

a)  Directory  Access  Application  Context; 

b)  Directory  System  Application  Context. 

6  Schema 

There  are  seven  (7)  major  topics  that  relate  to  schema. 

6.1      Support  of  Structures  and  Naming  Rules 

DSAs  shall  be  capable  of  supporting  (subject  to  refinements  laid  down  in  these  Agreements)  the  structure 
and  naming  rules  defined  in  the  Directory  Documents,  Part  7,  Annex  B. 

Part  7,  Annex  B  of  the  Directory  Documents  provides  a  framework  for  the  basic  use  of  the  Directory  In  terms 
of  the  objects  defined  in  Part  7.  It  does  not,  however,  form  part  of  the  standard  and, in  any  case,  permits 
structures  and  practices  which  may  be  undesirable.The  guidelines  below  provide  tighter  control  within  the 
Annex  B  frameworl<. 

It  is  recommended  that  only  an  entry  subordinate  to  Root  or  Country  may  use  a  StateOrProvinceName  AVA 
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as  an  RDN. 


6.2      Support  of  Object  Classes  and  Subclasses 

The  DSAs  shall  be  able  to  support  all  superclasses  of  the  supported  object  classes  (e.g.,  Top,  Person). 

Use  of  an  object  class  in  this  profile  or  the  standard  (or  a  subclass  derived  from  one  or  more  of  these  object 
classes) is  recommended  wherever  the  semantics  are  appropriate  for  the  application.The  derivation  of  a  new 
object  class  as  an  immediate  subclass  of  Top  should  be  avoided.  For  example,  to  represent  printers  in  the 
Directory,  one  can  derive  a  subclass  of  Device. 

An  entry  of  a  particular  object  class  may  contain  any  optional  attribute  listed  for  it  in  the  Directory 
Documents;  a  conformant  DSA  shall  be  able  to  support  all  these  optional  attributes. 

In  addition,  a  DSA  may  permit  any  locally  registered  attribute,  or  a  subset  of  these,  by  providing  the  local 
extension  facilities  permitted  by  unregistered  object  classes  (viz.  Directory  Documents,  Part  2,  clause  9.4.1 
(a)  and  Note). 


6.3      Support  of  Attribute  Types 

DSAs  shall  be  able  to  support  the  storage  and  use  of  attribute  type  information,  as  defined  in  the  Directory 
Documents,  Part  6,  including  their  use  in  naming  and  access  to  entries;  they  shall  also  support  the  definition 
of  new  attribute  types,  making  use  of  pre-existing  attribute  syntaxes. 

DSAs  shall  support  the  encoding,  decoding,  and  matching  of  all  the  attributes  in  the  Naming  Prefixes  of 
every  naming  context  they  hold  (ref  Directory  Documents,  Part  4,  clause  9).  These  attributes  may  include 
attributes  that  are  not  permitted  to  appear  in  entries  in  those  naming  contexts. 


6.4      Support  of  Attribute  Syntaxes 

Suggested  methods  for  the  Interpretation  of  selected  Attribute  Syntaxes  are  defined  in  annex  A. 


6.5      Naming  Contexts 

The  root  of  a  naming  context  shall  not  be  an  alias  entry. 
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6.6      Common  Profiles 

This  subclause  identifies  profiles  that  are  commonly  useful  for  various  applications  while  an 
application-specific  profile(s)  is  identified  by  the  application. 

6.6.1       OIW  Directory  Common  Application  Directory  Profile 

6.6.1.1  Standard  Application  Specific  Attributes  and  Attribute  Sets 

The  attributes  and  attribute  sets  in  the  Directory  Document,  Part  6,  associated  with  the  object  classes  listed 
below  are  required. 

6.6.1.2  Standard  Application  Specific  Object  Classes 

DSAs  shall  be  able  to  support  storage  and  use  of  the  object  classes  below,  as  defined  in  the  Directory 
Documents,  Part  7,  and  these  object  classes  are  expected  to  be  useful  for  a  range  of  applications. 

The  following  object  classes  are  mandated  by  the  standard: 

a)  Top; 

:    b)  DSA; 

c)  Alias. 

The  following  object  classes  are  expected  to  be  generally  useful  in  the  creation  of  the  upper  portion  of  the 
DIT: 

a)  Country; 

b)  Locality; 

c)  Application  Process; 

d)  Organization; 

e)  OrganizationalUnit. 

The  following  object  classes  are  expected  to  be  generally  useful  in  the  creation  of  DIT  leaf  entries: 

a)  Alias; 

b)  ApplicationProcess; 

c)  ApplicationEntity; 
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d)  DSA; 

e)  Device; 

f)  Group  of  Names; 

g)  OrganizationalPerson; 

h)  OrganizationalRole; 

i)  ResidentialPerson. 

6.6.2       OIW  Directory  Strong  Authentication  Directory  Profile 

6.6.2.1  Other  Profiles  Supported 

This  profile  is  used  in  conjunction  with  the  OIW  Directory  Common  Application  Directory  Profile. 

6.6.2.2  Standard  Application  Specific  Object  Classes 

The  following  object  classes  are  expected  to  be  generally  useful  for  applications  to  support  strong 
authentication: 

a)  Strong  Authentication  User; 

b)  Certification  Authority. 

6.7      Restrictions  on  Object  Class  Definitions 

An  object  class  may  not  be  defined  as  a  subclass  of  itself,  as  the  chain  of  superclasses  of  such  an  object 
class  would  be  a  closed  loop,  isolated  from  all  other  object  classes,  specifically  Top.  Such  isolation  is  clearly 
illegal. 
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7     Pragmatic  Constraints 

This  clause  describes  pragmatic  constraints  to  wliich  a  conformant  implementation  shall  adhere  in  addition 
to  those  specified  in  the  Directory  Documents.  The  pragmatic  constraints  can  be  divided  into  two  major 
areas.  The  first  includes  those  aspects  of  pragmatic  constraints  which  apply  to  scope  of  service  (see  7.1  and 
7.2).  The  second  includes  those  aspects  of  pragmatic  constraints  which  are  specific  to  particular  attribute 
types  (see  7.3). 


7*1      General  Constraints 
7.1.1       Character  Sets 

It  is  a  requirement  to  support  all  character  sets  and  other  name  forms  defined  in  the  Directory  Documents, 
Part  6.  Those  character  sets  include: 

■       ;  a)  T.61; 

b)  PrintableString; 

c)  NumericString. 


7.1.2        DSP  APDU  Size 


In  the  process  of  chaining  requests  it  is  possible  that  a  chaining  DSA  may  receive,  invoke  or  return  APDUs 
that  exceed  its  capacity.  It  is  a  minimum  requirement  that  invoke  APDUs  and  return  result  APDUs  shall  be 
accepted  unless  they  exceed  2**18  - 1  (i.e.,  262,143)  octets  in  size;in  this  case  they  may  be  discarded  and 
an  "unwillingToPerform"  error  reporting  service  shall  be  used. 


7.1.3       Service  Control  (SC)  Considerations 

This  agreement  recognizes  that  DUAs  may  automatically  supply  defaults  for  any  SC  parameter.  The  choice 
of  default  values  selected  (if  any)  is  seen  to  be  a  matter  of  local  policy  and  consumer  needs. 


7.1.4       Priority  Service  Control 

Priority  is  specified  as  a  service  control  argument  in  the  Directory  Documents.  The  following  statements 
represent  a  clarification  of  the  semantics  that  may  be  used  by  a  DSA  in  interpreting  and  operating  on  this 
parameter. 

The  logical  model  in  figure  4  may  be  considered  as  an  example  by  DSAs  that  implement  this  Service 
Control.  In  figure  4,  note  that: 

a)  the  DSA  maintains  three  logical  queues  corresponding  to  the  three  priority  levels; 
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b)  the  DSA  Scheduler  is  separate  and  distinct  from  any  scheduling  function  provided  by  the 
underlying  operating  system  or  control  program  services; 

c)  the  DSA  Scheduler  presents  jobs  to  the  Underlying  Operating  Services  for  execution  and  always 
presents  jobs  of  a  higher  priority  before  those  of  a  lower  priority; 

d)  the  DSA  Scheduler  will  not  preempt  a  request  once  It  has  been  passed  to  the  underlying 
operating  system  service. 


High 


\/ 


Medium 


Low 


DSA 

Scheduler 


\/ 


Underlying 
Protocol  Services 


Underlying  OS 
Services 


Figure  4  -  Logical  DSA  application  environment 


7.2      Constraints  on  Operations 


There  are  no  overall  constraints  upon  service  arguments  or  results  except  those  implied  in  7.1.2  of  this 
document. 


7.2.1 


Filters 


It  is  required  that  DSAs,  at  a  minimum,  support  8  nested  "Filter"  parameters,  and  a  total  limit  of  32  Filter 
Items.lf  these  limits  are  exceeded,  the  recipient  of  that  Search  Argument  may  return  the  Service  Problem 
"unwillingToPerform." 

7.2.2  Errors 

There  are  no  constraints  upon  any  Error  service  except  the  APDU  size  limit  as  defined  in  7.1.2. 


7.2.3       Error  Reporting  -  Detection  of  Search  Loop 

A  search  operation  may  encounter  a  looping  situation  when  the  search  encompasses  "whole-subtree,"  and 
an  alias  is  encountered  which  is  a  superior  to  some  other  subtree  that  has  been  encountered  during  the 
search. 
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DSAs  should  be  able  to  detect  this  situation.  One  possible  nriethod  is  by: 

a)  Maintaining  a  list  of  the  base  objects  of  searches  initiated  as  a  consequence  of  Step  5  of  Part 
4,  clause  18.7.2.2.1  of  the  Directory  Docunnents  (this  may  require  an  analysis  of  theTracelnformation 
field); 

b)  Determining  whether  a  new  base  object  is  superior  to  any  base  object  on  this  list. 

A  new  base  object  which  would  cause  a  loop  in  this  way  should  be  discarded  (i.e.,  should  not  cause  a  new 
search),  but  no  error  should  be  reported  by  an  error-reporting  service.  The  circumstances  should  be  logged 
so  that  it  may  be  reported  to  an  appropriate  Administrative  Authority  for  rectification. 

7.3      Constraints  Relevant  to  Specific  Attribute  Types 

Table  1  gives  pragmatic  constraints  associated  with  selected  attribute  types  specified  in  the  Directory 
Documents;  many  of  these  constraints  also  appear  and  are  the  same  in  the  CCITT  version  of  the  Directory 
Documents.  Each  constraint  in  table  1  is  given  in  terms  of  a  length  constraint.  The  length  constraint  for  a 
given  attribute  value  is  the  number  of  units  which  a  sending  entity  shall  not  exceed  and  which  a  receiving 
entity  shall  accept  and  process.  A  sending  entity  need  not  be  capable  of  sending  attribute  values  as  large 
as  the  length  constraints. 

Note  that  in  table  1  the  length  constraint  for  strings  is  expressed  as  the  number  of  allowable  characters. 
In  addition  to  the  constraints  given  in  table  1 ,  the  following  constraints  apply  to  alphabets  and  integer  values: 

a)  Alphabets:  T.61  Strings  used  as  attribute  values  shall  only  encode  graphic  characters  and 
spaces.  They  shall  not  contain  formatting  characters  (such  as  subscript)  or  other  control  characters; 

b)  Integer  Values:  DSAs  shall  be  required  to  "pass  through"  encoded  integer  attribute  values  of 
arbitrary  length  (e.g.,  when  chaining  a  Directory  operation).  No  Directory  component  (i.e.,  DUA  or 
DSA)  shall  be  deemed  non-conformant  if  it  encodes  integer  attribute  values  of  arbitrary  length. 

Components  of  the  Directory  are  required  to  support  (for  storage  and  processing),  as  a  minimum,  integer 
attribute  values  encoded  in  4  octets. 

8  Conformance 

The  following  subclauses  will  describe  various  aspects  of  Directory  conformance.  It  should  be  noted  that 
conformance  to  the  various  ASEs  and  conformance  to  the  Authentication  Framework  are  viewed  as  separate 
issues  and  are  presented  in  that  context. 
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8.1      DUA  Conformance 

Conformance  requirements  for  DUAs  are  adequately  specified  in  the  Directory  Documents,  Part  5,  clause 

9.1  and  the  Directory  Access  Profile  (see  8.6).  It  should  be  noted  that  the  DUA  conformance  is  based  on 
DAP  Protocol  and  not  the  User  Interface.  Not  all  options  available  in  the  standard  need  to  be  made  available 
to  the  user  of  the  DUA. 

It  is  recognized  that  DUAs  will  be  widely  differing  in  nature: 

a)  Some  are  intended  to  support  human  users,  some  application  users; 

b)  Particular  DUAs  may  not  support  particular  operations  because  the  application  that  they  support 
has  no  requirement;  others  will  be  general  purpose,  and  will  support  all  operations; 

c)  Some  DUAs  will  have  a  fixed  view  of  the  Directory  content  and  structure,  reflecting  the  usage 
of  The  Directory  by  a  particular  application;  others  will  have  a  more  flexible  view  which  can  be 
adapted  to  new  usages; 

d)  Some  DUAs  will  provide  automatic  referral  services  with  automatic  establishment  and  release 
of  associations;  others  will  place  the  burden  on  the  user; 

e)  Some  DUAs  will  provide  a  variety  of  authentication  means;  others  will  support  no  authentication; 

f)  Some  DUAs  will  handle  operations  synchronously;  others  will  have  the  capability  of  maintaining 
several  identifiable  dialogues  with  The  Directory  at  one  time. 

In  the  next  subclause,  different  types  of  DSAs  are  discussed.  The  DUA  is  independent  of  the  type  of  DSA 
it  is  communicating  with  and  does  not  need  to  know  what  type  of  DSA  it  is  communicating  with. 

8.2  DSA  Conformance 

Basic  conformance  requirements  for  a  DSA  are  defined  in  the  Directory  Documents,  Part  5,  clause  9.2.  Some 
of  the  terms  used  to  describe  DSA  conformance  are  summarized  below: 

a)  Centralized:  A  centralized  DSA  is  defined  as  one  that  contains  its  entire  relevant  DIT;  it  follows 
that  it  will  not  make  use  of  the  DSP  or  generate  referral  responses.  Since  this  model  only  contains 
a  single  DSA  it  is  not  subject  to  DSA  interworking  issues  and  will  always  provide  a  consistent  level 
of  service  and  results.  A  centralized  DSA  shall  be  fully  "protocol"  conformant  to  the  DAP; 

b)  Cooperating:  In  a  distributed  directory,  responsibility  for  various  portions  of  the  DIT  may  be 
"distributed"  among  multiple  DSAs.  On  a  per  operation  basis  we  define  a  DSA  to  be  holding  when 
it  is  responsible  for  the  fragment  of  the  DIB  in  which  a  given  entry  will  appear  if  it  exists;  we  define 
a  DSA  to  be  propagating  when  it  is  unable  to  complete  the  name  resolution  process. 

All  DSAs  shall  be  capable  of  acting  as  a  holder  and  a  propagator. 
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8.3  DSA  Conformance  Classes 

A  DSA  implementation  shall  satisfy  the  conformance  requirements  as  defined  in  the  Directory  Documents, 
Part  5,  subclause  9.2,and  shall  support  the  "Versions"  argument  of  "Bind." 

Per  the  conformance  clause  of  the  Directory  Documents,  a  DSA  shall  conform  to  the  abstract  syntax  of  the 
attribute  types  for  which  conformance  is  claimed.  These  attribute  types  shall  include  those  required  by  6.3 
of  this  Implementor's  Agreement. 

Additionally,  an  implementation  conformant  to  these  agreements  shall  state  which  of  the  following 
conformance  classes  it  implements: 

8.3.1  Conformance  Class  0  -  Centralized  DSA 

A  DSA  conformant  to  this  class  only  supports  the  DirectoryAccessAC. 

As  the  performance  of  Search  and  List  operations  can  consume  significant  resources,  the  policies  of  some 
centralized  DSAs  may  be  such  that  these  operations  will  not  be  performed.  For  these  cases,  the  reply  to 
requests  for  such  operations  would  be  a  Service  Error  with  the  "unwillingToPerform"  Sen/ice  Problem. 

8.3.2  Conformance  Class  1  -  Distributed  DSA 

A  DSA  implementation  conformant  to  this  class  shall  implement  all  the  operations  in  the  ASEs  that  are  part 
of  the  Application  context  for  which  it  claims  conformance.  It  shall  support  the  DirectoryAccessAC  and  it 
may  optionally  support  the  DirectorySystemAC. 

DSAs  conformant  to  these  Agreements  shall  support  the  OIW  Directory  Common  Application  Directory 
Profile.  In  addition,  DSAs  may  optionally  conform  to  the  OIW  Directory  Strong  Authentication  Directory 
Profile.  Future  versions  of  these  Agreements  may  allow  additional  possibilities  for  minimal  profile 
conformance. 

8.4  Authentication  Conformance 

A  Directory  System  may  choose  to  fmplement  various  levels  of  authentication  (Directory  Documents,  Part 
8).  We  define  the  following  levels  of  authentication  in  the  DS: 

a)  No  authentication  at  all;  (None); 

b)  Simple  Uncorroborated:  identification  without  verification; 

f  iiiet  c)    Simple  Uncorroborated  authentication  with  verification:  verified  identification  without  a 
password; 

d)  Simple  Corroborated  authentication:  verified  identification  with  a  password;  intended  to  make 
masquerading  difficult; 

e)  Strong  authentication:  identification  with  verification  using  cryptographic  techniques  intended 
to  make  masquerading,  in  practical  terms,  nearly  impossible. 


14 


Part  1 1  -  Directory  Services  Protocols 


December  1991  (Stable) 


The  "Authentication  Framework"  document  describes  the  specific  goal  of  each  authentication  level;  listed 
below  are  several  practical  uses  of  the  various  levels.^ 

Simple  Uncorroborated  authentication  may  be  desired  to  maintain  access  statistics  or  in  a  private 
network  where  the  initiator  is  implicitly  trusted  and  there  is  no  need  to  incur  the  additional  overhead 
of  more  sophisticated  authentication  methods. 

Simple  Corroborated  authentication  may  be  necessary  in  situations  where  strong  authentication 
is  not  practical,  (i.e.,  international  connection,  no  knowledge  of  algorithms  in  use,  etc.). 

Strong  authentication  will  be  required  for  secure  environments. 

A  DSA  that  implements  Simple  Corroborated  authentication  will  check  the  user  password  by  means  of  a 
compare  operation  on  the  user's  entry.  If  no  user  password  is  supplied  (Simple  Uncorroborated 
authentication)  the  DSA  will  validate  the  presence  of  the  entry  for  the  user,  by  a  read  operation  or  otherwise. 
The  authentication  will  fail  if  the  password  is  incorrect  or  if  the  user's  entry  does  not  exist. 

A  DSA  that  implements  Simple  Uncorroborated  authentication  without  verification  will  accept  simple 
credentials  without  validating  them. 

Implementations  claiming  conformance  shall,  as  a  minimum,  implement  None  and  Simple  Uncorroborated 
authentication  without  verification. 

8.5      Directory  Service  Conformance 

The  following  subclauses  will  describe  various  aspects  of  Directory  conformance.  Conformance  to  the 
Authentication  Framework  is  viewed  as  a  separate  issue  from  conformance  to  the  rest  of  the  Directory 
document  and  is  presented  in  that  context. 

Directory  Profiles  are  broken  into  two  subclauses.  Service  support  specifies  the  level  of  support  for 
operations  and  errors.  Protocol  support  specifies  the  protocol  elements  required  for  implementations  which 
claim  conformance  to  specified  operations. 

8.5.1       Service  Conformance 

To  specify  the  support  for  operations  and  errors,  two  classifications  are  used  as  follows. 
8.5.1.1         r:  required 

The  operation  shall  be  implemented  and  the  respective  error  shall  be  handled  for  conformance  to  these 
agreements. 

For  DUAs,  required  means: 


■"■It  is  the  case  that  some  DBAs  containing  public  information 
may  not  require  authentication. 
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a)  or  ARGUMENT  parameters,  create  the  DAP  protocol  elements  to  convey  the  service  request  to 
the  DSA; 

b)  or  RESULT  and  ERROR  parameters,  accept  the  DAP  protocol  elements. 
For  DSAs,  required  means: 

a)  or  ARGUMENT  parameters,  accept  the  protocol  elements  when  received  and  create  the  protocol 
elements  when  acting  as  a  requesting  DSA; 

b)  or  RESULT  and  ERROR  parameters,  be  able  to  convey  all  possible  results  when  responding  in 
either  the  DAP  or  DSP  protocols  and  when  receiving  results,  perform  additional  processing  as 
defined  for  cooperating  DSAs. 

8.5.1.2        n:  not  required 

It  is  left  to  implementations  as  to  whether  the  operation  or  error  is  implemented  or  not. 
8.5.2       Protocol  Conformance 

To  specify  the  support  for  protocol  elements,  four  classifications  are  used  as  follows. 

8.5.2.1  mi:  mandatory 

Generation  of  element  is  a  mandatory  static  conformance  requirement  (i.e.,  a  conformant  implementation 
shall  be  capable  of  generating  the  element). 

Generation  of  element  is  a  mandatory  dynamic  conformance  requirement  (i.e.,  the  element  shall  be  present 
in  all  instances  of  communication  which  use  the  element). 

The  terms  static  conformance  and  dynamic  conformance  are  defined  in  ISO  9646-1,  "OSI  Conformance 
Testing  Methodology  and  Framework,  Part  1 :  General  Concepts." 

8.5.2.2  G:  generate 

Generation  of  element  is  a  mandatory  static  conformance  requirement. 

Generation  of  element  is  a  conditional  dynamic  conformance  requirement;  the  condition  is: 

Where  a  DSA  is  a  propagating  DSA,  it  shall  be  capable  of  generating  the  protocol  element  as  received  in 
related  APDUs  received  from  other  DSAs.  Where  the  DSA  is  a  holding  DSA,  it  shall  be  capable  of  creating 
all  possible  values  of  a  protocol  element  unless  otherwise  noted  in  the  "comments"  line. 

8.5.2.3  S:  support 

When  receiving  protocol  elements,  implementations  of  these  agreements  shall  be  capable  of  accepting  these 
elements  without  error.  Actions  specified  in  the  Directory  documents  and  in  these  agreements  shall  be  taken. 
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8.5.2.4        O:  optional 

When  generating  protocol  elements: 

a)  Generation  of  element  is  an  optional  static  conformance  requirement.  If  the  implementor  claims 
support  for  the  corresponding  Directory  capability,  then  the  implementation  shall  be  capable  of 
generating  the  element; 

b)  Generation  of  element  is  an  optional  dynamic  conformance  requirement.  If  the  implementor 
claims  support  for  the  corresponding  Directory  capability,  then  the  element  shall  be  present  in 
instances  of  communication  which  use  the  element  (except  where  defaults  allow  otherwise). 

When  receiving  protocol  elements,  implementations  of  these  agreements  shall  be  capable  of  accepting  these 
elements  without  error.  However,  actions  specified  in  the  base  standard  and  in  these  agreements  may  be 
taken  but  are  not  required. 

Where  protocol  elements  are  nested,  the  classification  of  the  nested  protocol  elements  is  of  relevance  only 
when  the  immediately  containing  protocol  element  is  generated.  The  classification  of  the  protocol  elements 
at  the  highest  level  is  relative  with  respect  to  support  of  the  operation. 

Also  note  that  in  table  3,  some  rows  contain  two  support  classifications  in  the  DSA  column.  In  such  cases, 
the  support  classification  in  parentheses  applies  to  centralized  DSA's  only.  When  there  is  only  one  support 
classification  given,  it  applies  equally  to  centralized  and  non-centralized  DSA's. 

8.6  The  Directory  Access  Profile 

This  agreement  requires  implementations  of  the  DUA  to  provide  access  to  the  Directory  Sen/ices  as  defined 
in  the  DUA  column  in  table  2.  For  the  services  in  table  2  which  are  supported,  these  agreements  further 
require  DUAs  to  support  the  protocol  elements  as  defined  in  the  DUA  column  in  table  3  (parts  1  -  7). 

These  agreements  require  implementations  of  the  DSA  to  support  the  Directory  Services  as  defined  in  the 
DSA  column  in  table  2.  These  agreements  further  require  DSAs  to  support  the  protocol  elements  as  defined 
in  the  DSA  column  in  table  3.  Table  3  is  listed  in  seven  parts.  Note  that  the  requirements  for  a  centralized 
DSA  and  a  cooperating  DSA  are  different. 

8.7  The  Directory  System  Profile 

These  agreements  require  implementations  of  distributed  DSAs  which  provide  DSP  to  support  the  responder 
role  for  services  as  defined  in  table  4.  Further,  these  agreements  require  DSAs  to  support  the  protocol 
elements  as  specified  in  table  5.  Table  5  is  listed  in  nine  parts. 

DSAs  are  required  to  support  the  requestor  role  for  all  the  services  as  defined  in  table  4  if  conforming  to  the 
chained  mode  of  interaction. 
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8.8  Digital  Signature  Protocol  Conformance  Profile 

Table  6  and  table  7  provide  information  on  the  digital  signature  protocol  conformance  profile. 

Note  that  elements  in  CommonArguments  and  CommonResults  SecurityParameters  that  are  not  specified 
in  table  6  and  table  7  are  covered  in  the  Directory  Service  Protocol  Support  (table  5)  and  Directory  Access 
Protocol  Support  (table  3). 

8.9  Strong  Authentication  Protocol  Conformance  Profile 

Table  8  and  table  9  provide  information  on  the  strong  authentication  protocol  conformance  profile. 

8.10  Subtree  Specification  Classes 

This  profile  defines  three  classes  of  refinement  that  may  occur  in  subtree  specifications.  These  classes  may 
be  used  in  describing  units  of  replication  for  use  by  DISP  or  in  describing  DACDs  for  use  by  Basic  Access 
Control: 

•  Class  0  (Complete  Subtree):  A  subtree  definition  in  which  only  the  base  component  is  specified; 

•  Class  1  (Chop  Subtree):  A  subtree  definition  in  which  only  the  base  and  chop  components  are 
specified; 

'    •  Class  2  (Refined  Subtree):  A  subtree  definition  in  which  the  base,  chop,  and  specification-filter 
components  are  specified. 

8.11  Replication  Conformance 

NOTE  -  This  subclause  contains  agreements  on  the  forthcoming  edition  of  the  OS!  Directory  standard,  and 
is  based  on  the  DAM/DIS  Directory  Documents  referenced  in  2.1  of  these  agreements. 

A  DSA  implementing  DISP  shall  conform  to  the  basic  conformance  requirements  for  a  DSA  as  defined  in 
the  Directory  Documents,  part  5,  clause  9.2.  However,  it  is  not  required  for  such  a  DSA  to  be  either 
centralized  or  distributed  as  defined  by  8.3  of  this  implementation  agreement. 

8.11.1  Shadowing  Roles 

All  DSAs  implementing  DISP  shall  be  capable  of  acting  both  as  a  shadow  supplier  and  as  a  shadow 
consumer  as  defined  in  the  Directory  Documents,  part  9,  clause  3,  and  as  such  shall  meet  conformance 
requirements  stated  in  part  5,  9.3  and  9.4. 

8.11.2  Minimum  Shadowing  Requirements 

Additionally,  conformance  to  this  profile  requires  a  minimum  as  listed  below: 

a)      support  for  both  the  directoryShadowConsumerAC  application   context  and  the 
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directoryShadowSupplierAC  application  context; 

b)  support  for  an  updateMode  whose  mode  choice  includes  a  specification  of 
schedulingParameters; 

c)  support  for  schedulingParameters  specifications  which  specify  a  periodic  strategy. 
8.11.3      Support  for  Unit  of  Replication 

This  profile  defines  three  classes  regarding  the  level  of  refinement  to  be  supported  by  a  DSA  in  the  definition 
of  a  unit  of  replication.  The  provider  of  a  conforming  implementation  shall  state  which  of  the  following  Unit 
of  Replication  Conformance  Classes  the  implementation  supports: 

a)  Class  0  (Basic  UnitOfReplication):  A  DSA  conforming  to  this  class  shall  be  capable  of  shadowing 
a  Unit  of  Replication  with  the  following  characteristics: 

1)  the  area  includes  a  class  0  subtree  as  defined  in  8.10  of  these  agreements; 

2)  the  area  includes  a  specified  knowledgeType  (e.g.,  master,  copy,  or  both). 

b)  Class  1  (Intermediate  UnitOfReplication):  A  DSA  conforming  to  this  class  shall  fully  support  the 
Basic  UnitOfReplication  and,  in  addition,  shall  be  capable  of  shadowing  a  unit  of  replication  with  the 
following  characteristics: 

1)  the  area  includes  a  class  1  subtree  as  defined  in  8.10  of  these  agreements; 

2)  the  knowledge  includes  the  extendedKnowledge  element  with  value  TRUE. 

c)  Class  2  -  (Maximal  UnitOfReplication):  a  DSA  conforming  to  this  class  shall  fully  support  the 
Intermediate  UnitOfReplication  and,  in  addition,  shall  be  capable  of  shadowing  a  unit  of  replication 
whose  specification  uses  AttributeSelection  (including  selection  on  class).  Furthermore,  a  DSA 
conforming  to  this  class  shall  be  capable  of  supporting  overlapping  replicated  areas  as  described 
in  the  Directory  Documents,  part  9,  9.2.5. 


NOTES 


1  No  replication  conformance  class  requires  (nor  precludes)  support  for  a  class  2  subtree  specification. 

2  Filtering  using  a  specification-filter  in  the  definition  of  a  subtree  allows  filtering  on  class  when  specifying 
which  entries  are  to  be  part  of  the  subtree. 

3  AttributeSelection  is  used  in  shadowing  to  determine  which  attributes  of  the  entries  in  a  subtree  will  be 
shadowed.  ClassAttributeSelection  allows  choosing  specific  attributes  or  all  attributes  in  an  class.  A  list  of 
classes  for  shadowing  can  be  devised  using  a  sequence  of  class  and  classAttributes. 
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8.12    Recommended  Practices  for  Shadowing 

NOTE  -  This  subclause  contains  agreements  on  the  forthcoming  edition  of  the  OSI  Directory  standard,  and 
is  based  on  the  DAM/DIS  Directory  Documents  referenced  in  2.1  of  these  agreements. 

8.12.1  APDU  Size 

In  shadowing,  updates  for  an  entire  Unit  of  Replication  are  carred  in  one  APDU.  Since  the  size  of  such  an 
APDU  is  application-specific,  no  pragmatic  constraint  has  been  specified  in  the  Directory  Documents  or 
Implementation  Agreements. 

Some  examples  of  APDU  size  implementors  can  expect  would  be  useful.  For  instance,  an  entry  size  of  2000 
octets  and  a  Unit  of  Replication  consisting  of  2000  entries  would  result  in  a  APDU  of  4  Megabytes.  It  is 
recommended  that  DSA  implementations  be  capable  of  supporting  an  APDU  of  at  least  this  size.  This 
example  does  not  reflect  entries  which  include  large  attributes,  such  as  photographic  images. 

8.12.2  Duplicate  Shadow  Agreements 

Administrators  should  not  allow  duplicate  shadow  agreements  between  DSAs.  Duplicate  shadow 
agreements  are  those  which  include  the  same  consumer,  supplier,  and  Unit  of  Replication. 

8.12.3  Consistency  Between  Supplier  and  Consumer  Information 

After  an  updateShadow  operation,  the  standard  does  not  guarantee  consistency  between  the  resulting 
shadowed  information  in  the  consumer  DSA  and  the  information  in  the  replicated  area  in  the  supplier  DSA, 
since  changes  may  be  made  during  assembly  of  the  APDU  containing  the  shadowed  information. 

If  consistency  between  the  supplier  and  consumer  information  is  required,  the  contents  of  the  replicated  area 
in  the  supplier  DSA  must  not  be  modified  while  the  APDU  is  being  assembled. 

However,  the  shadowed  information  must  be  internally  consistent.  For  example,  while  the  shadowed 
information  is  being  assembled,  changing  a  distinguished  name  within  the  replicated  area  could  lead  to 
internal  inconsistency. 

8.12.4  Management  of  Shadowing  Agreements  Without  DOP 

For  DSAs  not  supporting  the  directoryOperationalBindingManagementAC  as  defined  in  the  Directory 
Documents,  part  5,  management  of  shadowing  agreements  is  by  out-of-band  means.  The  results  of 
procedures  followed  by  such  DSAs  must  be  the  same  as  if  the  DSAs  had  managed  the  same  agreements 
using  the  procedure  for  operational  binding  management  outlined  in  8.2  of  the  Directory  Documents,  part 
9. 

For  example,  when  shadowing  DSAs  arrange  to  modify  the  parameters  of  an  existing  shadowing  agreement, 
they  must  revise  the  AgreementID  so  that  its  version  component  is  incremented. 


20 


Part  1 1  -  Directory  Services  Protocols 


December  1991  (Stable) 


9     Distributed  Operations 

The  following  requirements  apply  to  DSAs  supporting  distributed  operations: 

DSAs  supporting  authentication  (e.g.,  sinnple  authentication  by  name  and  password)  shall  be  able 
to  invoke  DSP  operations  to  carry  out  authentication  by  reference  to  other  DSAs.  Thus  all  such 
DSAs  shall  support  the  DSP  protocol.  The  requirement  is  implied  by  the  Directory  Documents. 

9.1      Referrals  and  Chaining 

It  is  recommended  that  a  DSA  which  has  chained  a  request  act  upon  any  referrals  it  receives  rather  than 
returning  them  to  the  requestor  if  the  "preferChaining"  service  control  is  present. 


9.2  Tracelnformation 

A  Tracelnformation  value  carries  forward  a  record  of  the  DSAs  which  have  been  involved  in  the  performance 
of  an  operation.lt  is  used  to  detect  the  existence  of,  or  avoid,  loops  which  might  arise  from  inconsistent 
knowledge  or  from  the  presence  of  alias  loops  in  the  DIT. 

Each  DSA  which  is  propagating  an  operation  to  another,  adds  a  new  item  to  the  trace  information.  If  the 
propagation  of  a  Search  operation  involves  the  creation  of  a  new  Search  (cf  Directory  Documents,  Part  4, 
clause  18.7.2.2.2),  the  trace  information  shall  not  be  re-set,  but  the  full  trace  information  for  the  overall 
Search  operation  to  the  point  where  the  new  Search  was  generated  shall  be  included  in  the  new  Search. 


10   Underlying  Services 

This  section  specifies  requirements  over  and  above  those  given  in  the  Directory  Documents. 


10.1  ROSE 

It  should  be  noted  that  support  of  "abandon"  implies  support  of  operation  class  2. 


10.2  Session 

All  directory  implementations  are  required  to  support  Session  Version  2. 
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10.3  ACSE 

The  A-ABORT  service  is  required  by  association-accepting  DSAs  to  escape  unwanted  associations,  whicli, 
under  the  ROSE  protocol,  they  cannot  release.  In  all  other  cases  (association-initiating  DSAs  and  DUAs)  it 
may  be  preferable  (though  not  required)  to  escape  associations  using  UNBIND  rather  than  abort. 

The  aborting  DUA  or  DSA  may  optionally  use  the  user  information  field  of  the  A-ABORT.  Such  information, 
however,  is  only  meaningful  for  diagnostic  purposes  and  its  use  is  not  covered  by  these  Agreements. 

1 1  Access  Control 

Guidelines  relating  to  access  control  can  be  found  in  Annex  F  of  the  Directory  Documents,  Part  2. 

12  Test  Considerations 

This  clause  outlines  some  items  that  implementors  may  wish  to  consider  in  terms  of  testing  expectations; 
additionally,  future  conformance  testers  may  wish  to  consider  these  items  when  developing  tests. 

12.1     Major  Elements  of  Architecture 

One  important  aspect  of  testing  is  to  confirm  the  correct  behavior  of  DSAs  and  DUAs  with  respect  to  major 
elements  of  the  directory  architecture. 

Such  major  elements  include: 

a)  Conformance  Statement; 

b)  Distinguished  names  (e.g.,  name  resolution,  equivalence  of  various  forms); 

,  c)  Entries  and  Attributes  (e.g.,  accessibility  by  operations,  compliance  with  rules); 

d)  Handling  of  distributed  operations  (e.g.,  naming  contexts  and  knowledge); 

e)  Schemas: 

1)  Structure  rules  (e.g.,  storage  and  maintenance  of  structure  and  of  naming  rules); 

2)  Object  classes  and  sub-classes  (e.g.,  storage  and  extension  of  rules  for  object 
attributes); 

3)  Attribute  types  (e.g.,  storage  and  maintenance  of  syntax  classes  and  rules  for  multi  or 
single  valued  attributes); 

4)  Attribute  syntax  (e.g.,  maintenance  and  support  for  attribute  value  testing  and  matching, 
to  specification  for  a  defined  set  of  attribute  types); 
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f)  Operations: 

1)  all  operations; 

2)  correct  function; 

3)  correct  result; 

4)  correct  responses; 

g)  Aliases  (e.g.,correct  resolution,  error  responses); 

h)  Authentication  and  Access  Control  (e.g.,  linnltation  of  modify  access); 

I)  ROSE  (e.g.,  correct  handling  of  invokes,  results,  rejects,  and  invoke  ids); 

j)  ACSE  (e.g.,  association  establishment  /  refusal  for  invalid  application  contexts.etc). 


12.2    Search  Operation 

Testing  of  support  for  filter  items  should  be  reasonable.  It  is  not  expected  that  DSAs  will  be  able  to  handle 
worst  case  testing  in  this  area. 


1 3  Errors 

This  clause  provides  clarification  of  the  semantics  of  various  operation  errors  and  implementation  guidelines 
on  their  usage. 


13.1     Permanent  vs.  Temporary  Service  Errors 

This  subclause  provides  some  clarification  regarding  the  usage  of  the  Service  Errors  busy,  unavailable,  and 
unwillingToPerform. 

The  error  busy  is  particularly  transient.  It  is  returned  when  one  or  more  of  The  Directory's  internal  resources 
are  being  used  to  their  capacity  and,  hence,  the  requested  operation  cannot,  for  the  moment,  be  performed. 
The  Directory  should  be  able  to  recover  from  this  type  of  resource  depletion  after  a  short  while. 

The  error  unavailable  is  also  temporary  but  somewhat  less  transient.  It  indicates  that  The  Directory  (or  some 
part  of  It) is  currently  unavailable  and  may  continue  to  be  unavailable  for  a  reasonably  long  period  of  time. 
For  example,  this  error  is  returned  when  a  given  DSA  is  functionally  disabled,  or  when  a  specific  part  of  the 
DIB  Is  undergoing  reconfiguration. 

The  error  unwillingToPerform  has  a  permanent  connotation.  It  indicates  that  The  Directory  cannot  perform 
the  requested  operation  because  it  v/ould  require  resources  beyond  its  capacity.  For  example,  this  error  may 
be  returned  by  a  DSA  if  satisfying  a  request  would  result  in  the  generation  of  an  APDU  in  excess  of  32767 
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octets. 


13.2    Guidelines  for  Error  Handling 


13.2.1  Introduction 

This  subclause  provides  a  recommended  mapping  of  error  situations  which  may  be  encountered  to  ROSE 
Rejects  or  to  the  errors  provided  in  the  DAP,  DSP,  and  DISP  protocols  of  the  Directory  Documents. 

The  Directory  Documents  are  not  adequately  definitive  about  the  handling  of  errors.  In  this  document,  more 
explicit  guidelines  are  given. 

Error  situations  are  defined  by: 

a)  Symptom  (i.e.,the  manner  in  which  the  error  was  detected); 

b)  Situation  (i.e.,  the  circumstance  or  phase  during  which  the  error  was  detected.  For  each  possible 
situation,  the  error-handling  procedure  needs  to  be  defined). 


13.2.2  Symptoms 

Table  10  describes  a  set  of  symptoms;  the  set  is  not  necessarily  exhaustive.  Each  is  identified  by  a  title 
which  is  used  later  in  describing  error  actions.  The  title  used  for  each  symptom  is  not  intended  to  imply  any 
particular  usage  in  a  particular  implementation. 


13.2.3  Situations 

Table  1 1  identifies  recognized  situations  within  which  particular  symptoms  may  give  rise  to  distinct  error 
actions. 


13.2.4      Error  Actions 

Table  13  summarizes  specific  error  actions  for  each  possible  combination  of  symptom  and  situation. 
Symptoms  are  described  in  13.2.2  and  situations  are  described  in  13.2.3. 

Each  entry  in  table  13  corresponds  to  the  symptom  in  the  left-most  column  and  the  situation  given  in  the 

column  header.  Each  entry  may  specify: 

a)  a  specific  error  action.  The  error  action  is  described  using  the  notation  shown  in  table  12; 

b)  a  specific  error  action  and  a  relevant  note.  The  note  will  be  indicated  by  a  number  enclosed  in 
parentheses.  The  notes  can  be  found  at  the  end  of  table  13; 
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c)  only  a  relevant  note; 

d)  a  blank  (which  indicates  the  corresponding  combination  of  symptom  and  situation  is  not 
meaningful  In  the  context  of  these  Agreements). 

The  entries  in  table  1 3  which  specify  a  specific  error  action  will  do  so  using  the  notation  shown  in  table  1 2. 

13.2.5  Reporting 

In  addition  to  the  use  of  error-reporting  services,  DSAs  should  implement  logging  services  to  assist  in 
management  of  the  Directory.  The  list  below  describes  classes  of  error  which  should  be  logged. Note  that 
the  list  is  not  necessarily  complete: 

a)  Errors  Indicating  attempted  breaches  of  security; 

b)  Errors  indicating  local  software  or  hardware  malfunction; 

c)  Errors  indicating  malfunction  or  other  unacceptable  behavior  on  the  part  of  the  invoker  of  an 
operation; 

d)  Errors  indicating  loss  of  chaining  service  by  another  DSA; 

e)  Error  conditions  that  would  be  difficult  to  diagnose  with  the  level  of  detail  supplied  over  the 
protocol; 

f)  Aborts  and  other  exceptional  communications  events. 
The  form  and  accessibility  of  any  such  logs  is  for  further  study. 

14  Specific  Authentication  Schemes 

This  clause  identifies  authentiction  algorithms  for  use  in  Directory  authentication.  Informative  text  and  ASN.1 
definitions  describing  these  algorithms  appears  in  part  12  (Security).  Use  of  algorithms  other  than  those 
cited  in  this  clause  or  described  in  the  Directory  Documents  is  by  bilateral  agreement. 

14.1     Specific  Strong  Authentication  Schemes 

This  subclause  cites  one  alternative  to  the  RSA  digital  signature  scheme,  the  "EIGamal"  digital  signature 
scheme.  Future  contributions  may  result  in  other  alternatives  being  added  to  this  subclause. 

Implementors  may  choose  to  provide  digital  signature  capability  based  on  RSA,  EIGamal,  or  some  other 
scheme  appropriate  for  use  in  the  OSI  Directory  environment. 

It  should  be  noted  that  RSA  and  EIGamal  are  governed  by  U.S.A.  patent  law. 
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14.1.1 


EIGamal 


The  EIGamal  digital  signature  scheme  was  originally  described  by  Taher  EIGamal  in  [ELGA85].  Part  12 
(Security)  of  these  agreements  contains  details  on  the  use  of  EIGamal,  Including  an  informative  description 
of  the  scheme  using  the  notation  described  in  part  8  of  the  Directory  Documents  and  known  constraints  on 
algorithm  parameters. 


14.1.2      One-way  Hash  Functions 

This  subclause  cites  alternative  one-way  hash  functions  for  use  in  Strong  and  Protected  Simple 
Authentication.  The  Security  SIG  continues  to  investigate  the  security  of  additional  one-way  hash  functions, 
and  the  Directory  Services  SIG  will  consider  the  applicability  of  these  hash  functions  to  Directory 
authentication. 

A  recent  development  in  this  area  is  the  citation  by  the  Security  SIG  of  RSA  MD4.  In  another  recent 
development,  the  two-pass  application  of  the  SNEFRU  algorithm  was  announced  by  Ralph  Merkle  to  have 
been  broken.  Future  study  of  MD4  and  other  contributions  may  result  in  other  additions  to  this  subclause. 

At  the  present  time,  Implementors  may  choose  to  provide  one-way  hash  functionality  based  on  MD2  or  some 
other  scheme  aplpropriate  for  use  In  the  OSI  Directory  environment. 


14.1.2.1        SQUARE-MOD-N  Algorithm 

Recent  research  regarding  the  square-mod-n  one-way  hash  function  described  in  Annex  D  of  the  Directory 
Documents,  Part  8,  has  revealed  that  the  function  is  not  secure.  Its  use,  therefore.  Is  discouraged. 


14.1.2.2       MD2  Algorithm 

MD2  is  a  one-way  hash  function  and  is  described  In  [RFC1115]. 


14.1.2.3       Use  Of  One-Way  Hash  Functions  in  Forming  Signatures 

MD2  may  be  used  to  form  digital  signatures  in  conjunction  with  RSA  or  EIGamal. 


14.1.3      ASN.1  for  Strong  Authentication  Algorithms 

This  subclause  defines  object  identifiers  assigned  to  authentication  algorithms.  The  definitions  take  the  form 
of  the  ASN.1  module,  "OIWAIgorlthmObjectldentifiers." 
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OIWAlgorithmOb jectldentif iers  {iso(l)  identif ied-oraanization( 3 ) 

oiw(14)  dssig(7)  oIWAlgorithmObjectldentif iers(l) } 
DEFINITIONS  ::= 
BEGIN 

EXPORTS 

md2,  md2WithRSA,  elGamal,  md2Wi thElGamal ; 

IMPORTS 

authent  i  cat  ionFr  eimework 

FROM  UsefulDef initions  { joint-iso-ccitt  ds(5)  niodules(l) 

usef ulDef initions ( 0 ) ) 

ALGORITHM 

FROM  Authent i cat ionFr amework  authent icationFramework; 

—  categories  of  object  identifiers 

algorithm  OBJECT  IDENTIFIER  ::=  {iso(l)  identif ied-organization( 3 ) 

oiw(14)  dssig(7)  algorithm( 2 ) } 

encriptionAlgorithm  OBJECT  IDENTIFIER  ::=  {algorithm  1} 

hashAlgorthm  OBJECT  IDENTIFIER  ::=  {algorithm  2) 

signatureAlgorithm  OBJECT  IDENTIFIER  ::=  {algorithm  3) 

—  algorithms 

md2  ALGORITHM 

PARAMETER  NULL 

::=  {hashAlgorithm  1} 

md2WithRsa  ALGORITHM 
PARAMETER  NULL 
::=  {signatureAlgorithm  1} 

elGamal  ALGORITHM 
PARAMETER  NULL 
::=  {encrypt ionAlgorithm  l} 


md2Wi thElGamal  ALGORITHM 
PARAMETER  NULL 
::=  {signatureAlgorithm  2} 

END  —  of  Algorithm  Object  Identifier  Definitions 
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14.2    Protected  Simple  Authentication 

Protecting  the  user's  distinguished  name  and  password  provides  greater  degrees  of  security  than  where 
passwords  are  not  protected. 

The  procedure  for  achieving  this  protection,  referred  to  as  protected  simple  authentication,  is  outlined  in  the 
Directory  Documents,  Part  8,  clause  5.3.  The  approach  by  which  protected  identifying  information  may  be 
generated  is  outlined  in  the  Directory  Documents, Part  8,  clause  5.4.  For  the  purpose  of  these  agreements, 
/1  and  f2  as  specified  in  the  Directory  Documents,  Part  8,  clause  5.4  are  identical  MD2  one-way  functions. 
The  algorithms  for  implementation  of  the  MD2  one-way  function  are  described  in  [RFC1 115]  (see  D.3).  Note 
that  the  use  of  MD2  maybe  subject  to  licensing  agreement.  Use  of  other  algorithms  for  other  one-way 
functions  is  by  bilateral  agreement. 

User  A  generates  Protected2  as  specified  in  the  Directory  Documents,  Part  8,  clause  5.4.  Authenticator2  is 
then  conveyed  to  B  in  the  form  of  Simple  Credentials.  Table  14  shows  the  relationship  between 
SimpleCredentialfields  and  the  elements  of  protected  simple  authentication  as  shown  in  figure  2  of  the 
Directory  Documents,  Part  8. 


14.3    Simple  Authentication 

There  are  two  major  classes  of  authentication  supported  by  the  Directory  (i.e.,  simple  and  strong 
authentication).  Simple  authentication  is  based  on  a  password  being  passed  between  the  two  associated 
entities  (e.g.,  between  a  Directory  User  and  a  DUA,  or  between  two  DSAs).  In  the  case  of  interaction  (  0 
between  a  Directory  User  and  a  DUA,  the  password  is  compared  in  some  way  with  the  password  attribute 
in  the  user's  entry  in  the  Directory.  In  the  case  of  interaction  between  two  DSAs,  this  cannot  be  done  since 
the  DSA  object  class,  as  defined  in  the  Directory  Documents  (Part  7,  clause  6.14)  does  not  contain  a 
password  attribute. 

To  facilitate  simple  authentication  between  DSAs,it  is  recommended  that  a  DSA  have  local  access  to  a  list 
of  one  or  more  known  DSAs,  with  a  copy  of  each  known  DSA's  password.  Maintenance  of  that  information 
is  done  through  the  use  of  bilateral  agreements  between  DSA  administrators. 


11 


28 


Part  1 1  -  Directory  Services  Protocols  December  1 991  (Stable) 


Table  1  -  Pragmatic  constraints  for  selected  attributes 


Attribute  Type 

Content 

Constraints 

Primary 
Source 

Notes 

Aiiaseu  UDjeci  iName 

uisiinguisnaa 
Name 

iNoie  o 

Dusiness  oaieyory 

1  .D 1  or  rriniauie 
String 

ULruusiness- 
category  128 

X.520 

Common  Name 

T.61  or  Printable 
String 

ub-common-  name 
64 

CCITT 
X.520 

Country  Name 

Printable  String 

2 

ISO  3166 

Description 

T.61  or  Printable 
String 

ub-description  1024 

CCITT 
X.520 

About  1  screen  full 

Destination  Indicator 

Printable  String 

ub-destination- 
indicator  128 

CCITT 
X.520 

Facsimile  Telephone 
Number 

Facsimile 

Telephone 

Number 

ub-telephone-numb 
er32 

CCITT 
X.520 

Optionally  includes 
G3  non-basic  pa- 
rameters (Upper 
Dounus  rrs; 

Intornatinnal  I^PIM 

Number 

Ml  irY^orlr*  Qtrlr*/^ 

i>iuiiiciiu  ouiiiy 

UU-loUl  l-dUUlcoo   1  O 

X.520 

ISDN  Number 

Information 

1  .O  1  or  r  rilUaUlo 

String 

MOOUl    1   oUI  CCf  1  lull 

LUQ^dlliy  HaiTH? 

1  .D 1  or  r  riniaDi© 
String 

uo-iocanTy-nam© 
128 

x.520 

Mpmhpr 

Name 

Note  3 

Object  Class 

Object  Identifier 

256  octets 

OIW 

Organization  Name 

T.61  or  Printable 
String 

ub-organization-na 
me  64 

CCITT 
X.520 

Organizational  Unit 
Name 

T.61  or  Printable 
String 

ub-organizational- 
unit-  name  64 

CCITT 
X.520 

Owner 

Distinguished 
Name 

Note  3 

Physical  Delivery 
OfficeName 

T.61  or  Printable 
String 

ub-physical-office-n 
ame  128 

CCITT 
X.520 
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Table  1  -  Pragmatic  constraints  for  selected  attributes  (continued) 


Attribute  Type 

Content 

Constraints 

Primary 
Source 

Notes 

Post  Office  Box 

T.61  or  Printable 
String 

ub-post-office-box 
40 

CCITT 
X.520 

Postal  Address 

Postal  Address 

ub-postal-line6 
ub-postal-string30 

CCITT 
X.520 

UPU 

Postal  Code 

T.61  or  Printable 
String 

ub-postal-code  40 

CCITT 
X.520 

Presentation 
Address 

Presentation 
Address 

224  octets 

NIST 

Note  2(page  ?), 
ISO  7498.3  & 
X.200 

Registered  Address 

Postal  Address 

ub-postal-line6 
ub-postal-string30 

CCITT 

X.520 

Role  Occupant 

Distinguished 
Name 

Note  3 

Searcfi  Guide 

Guide 

256 

OIW 

See  Also 

Distinguished 
Name 

Note  3  (page  ?) 

Serial  Number 

Printable  String 

ub-serial-number  64 

CCITT 
X.520 

State  or  Province 
Name 

T.61  or  Printable 
String 

ub-state-name  128 

CCITT 
X.520 

Street  Address 

T.61  or  Printable 
String 

ub-street-address 
128 

CCITT 
X.520 

Supported 
Application  Context 

Object  Identifier 

256 

OIW 

Surname 

T.61  or  Printable 
String 

ub-surname  64 

CCITT 
X.520 

Telephone  Number 

Printable  String 

ub-telephone-numb 
er32 

CCITT 
X.520 

E.123 
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Table  1  -  Pragmatic  constraints  for  selected  attributes  (concluded) 


Attribute  Type 

Content 

Constraints 

Prinnary 
Source 

Notes 

Teletex  Terminal 
Identifier 

Teletex  Terminal 
Identifier 

ub-teletex-terminal-i 
d  1024 

CCITT 
X.520 

Optionally  includes 
Teletex  non-basic 
parameters  (upper 
bound  ffs) 

Telex  Number 

Telex  Number 

ub-telex-number14 
ub-country-code4 
ub-answerback  8 

CCITT 
X.520 

Contains  sequence 
of  telex  number, 
country  code,  and 
answerback 

Title 

T.61  or  Printable 
String 

ub-title  64 

CCITT 
X.520 

User  Password 

Octet  String 

ub-user-password 
128 

CCITT 
X.520 

Allow  long  pass- 
words generated 
by  machine 

X.121  Address 

Numeric  String 

ub-xl  21 -address  15 

CCITT 
X.520 

X.121 

NOTES 

1  The  pragmatic  constraints  of  these  parameters  are  defined  in  other  standards.  We  will 
accommodate  these  values  in  our  pragmatic  constraints. 

2  Presentation  address  is  composed  of  "X'  NSAP  addresses,  and  three  selectors,  (20X  +  32 
+  16  +  16),  e.g.,  if  X=  1,  this  would  be  84.  These  numbers  are  based  on  the  most  recent 
implementors'  agreements.  With  8  NSAP  addresses  this  value  is  224. 

3  Pragmatic  constraints  are  only  applied  to  the  individual  components  of  Distinguished  Name 
as  defined  in  the  Directory  Documents,  Part  2.  Not  all  components  of  a  DN  will  necessarily  be 
understood  by  an  implementation. 

4  Implementors  should  be  aware  that  constraints  on  Postal  Address  may  not  be  sufficient  for 
some  markets. 
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Table  2  -  Directory  access  service  support 


Support  Classification 

Operations  and  Errors 

DUA 

DSA 

Comments 

-  BIND  and  UNBIND  - 

DirectoryBind 

r 

r 

DirectoryUnbind 

r 

r 

-  OPERATIONS  - 

-  READ  OPERATIONS- 

n 

r 

Compare 

n 

r 

Abandon 

n 

r  (note  2) 

-  SEARCH  OPERATIONS  - 

List 

n 

r  (note  1) 

Search 

n 

r  (note  1) 

-  MODIFY  OPERATIONS  - 

AddEntry 

r 

RemoveEntry 

n 

r 

ModifyEntry 

n 

r 

ModifyRDN 

n 

r 

-  ERRORS  ~ 

Abandoned 

(note  4)r 

AbandonedFailed 

(note  4)r 

AttributeError 

(note  4)r 

NameError 

(note  4)r 

Referral 

(note  4) 

r(note  3) 
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Table  2  -  Directory  access  service  support  (concluded) 


Support  Classification 

Operations  and  Errors 

DUA 

DSA 

Comments 

SecurityError 

(note  4) 

r 

ServiceError 

(note  4) 

r 

UpdateError 

(note  4) 

4 

NOTES 

1  As  performance  of  Search  and  List  operations  can  consume  significant  resources,  the 
policies  of  some  centralized  DSAs  may  be  that  such  operations  will  not  be  performed.  For 
these  cases,  the  reply  to  the  requests  for  such  operations  would  be  ServiceError  with  the 
"unwillingToPerform"  Service  Problem. 

2  Reference  Directory  Documents,  Part  3,  clause  9.3.6 

3  Centralized  DSAs  would  not  generate  referrals. 

4  See  EntrylnformationSelection  information  under  Common  Data  Types  (table  3,  Part  6) 
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Table  3  -  DAP  protocol  support 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

-  BIND  and  UNBIND  - 

DirectoryBind 

DirectoryBindArgument 

M 

o 

o 

credentials 

U 

b 

simple 

0 

s 

name 

G 

s 

validity 

0 

0 

password 

G 

s 

strong 

.                                         '  ■■ 

H    • ,  ...•it-..,  ■ ■  V 

0 

0 

See  Strong  Authentication 
Protocol  Conformance  Profile  for 
requirements  when  strong 
authentication  is  supported. 

1  externalProcedure 

0 

0 

versions 

0 

s 

Supported  value:  v1988 

DirectoryBindResult       , -fs^.'  i 
credentials 

,1 

S 

G 

0 

G 

Shall  be  the  same  CHOICE  as  in 
DirectoryBindArgument. 

simple  ; 

0 

G 

name 

S 

G 

i  validity 

0 

0 

j?    V  password 

0 

0 

;j     ,  strong 

0 

0 

See  Strong  Authentication 
Protocol  Conformance  Profile  for 
requirements  when  strong 
authentication  is  supported. 

externalProcedure 

0 

0 

versions 

s 

0 

Supported  value:  v1988 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

DirectoryBindError 

S 

G 

versions 

S 

0 

Supported  value:  v1988 

ServiceProblem 

S 

G 

Supported  value:  unavailable 

SecurityProblem 

S 

G 

Supported  values: 

inappropriateAuthentication, 

invalidCredentials 

DirectoryUnbind 

The  DirectoryUnbind  has  no 
arguments. 

-  OPERATIONS,  ARGUMENTS  AND  RESULTS  - 

-  READ  OPERATIONS  - 

Read 

ReadArgument 

M 

S 

object 

M 

S 

selection 

0 

S 

See  note  2 

CommonArguments 

0 

S 

ReadResult 

S 

G 

entry 

S 

M 

CommonResults 

S 

G 

Compare 

CompareArgument 

M 

S 

object 

M 

S 

purported 

M 

S 

CommonArguments 

0 

S 

CompareResult 

S 

G 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

S 

G 

S 

M 

fromFntrv 

S 

G 

^^V^l  1  II  1  1^1  II  t^OUKO 

S 

G 

Abandon 

/AL/dl  IVJL/I  \r\\  UUI 1 ICI 11 

M 

S 

M 

S 

AhandonRpsult 

S 

G 

-  "^iFARrH  nPFRATIDN*?  - 

O  I— #\i » wi  1       1  i_  1 1  r\  1  1  \_/ 1  '•o 

List 

ListArgument 

M 

S 

object 

M 

S 

CommonArguments 

0 

S 

ListResuH 

S 

G 

listlnfo 

S 

G 

S 

G 

subordinates 

S 

M 

Rel.DistinguishedName 

S 

M 

For  the  case  where  subordinates 
is  empty  set,  RDN  is  absent. 

aliasEntry 

S 

G 

fromEntry 

S 

G 

partialOutconneQualifier 

S 

G 

ConnmonResults 

S 

G 

UncorrelatedListlnfo 

S 

G(0) 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

ListResult 

S 

G 

See  note  1  for  additional 
information  related  to  the  DSA 
support  classification. 

Search 

SearchArgument 

M 

s 

baseObject 

M 

o 

o 

subset 

0 

S 

filter 

0 

S 

searchAliases 

0 

s 

selection 

0 

S 

CommonArguments 

0 

S 

SearchResult 

s 

G 

searchinfo 

s 

G 

DistinguishedName 

s 

G 

entries 

s 

M 

partialOutcomeQualifier 

s 

G 

CommonResults 

s 

G 

uncorrelatedSearchinfo 

s 

G  (O) 

SearchResult 

s 

G 

partialOutcomeQualifier 

s 

G 

limitProblem 

s 

G 

unexplored 

s 

G 

unavailableCriticalExt 

s 

0 

-  MODIFY  OPERATIONS  - 

AddEntry 

AddEntryArgument 

M 

s 
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Table 

3  -  DAP  protocol  support 

(continued) 

Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

object 

M 

S 

entry 

M 

s 

CommonArgument 

0 

s 

AddEntryResult 

S 

G 

RemoveEntry 

RemoveEntryArgument 

M 

IVI 

s 

object 

M 

IVI 

s 

CommonArguments 

s 

RemoveEntryResult 

q 
o 

G 

ModifyEntry 

ModifyEntryArgument  ; 

M 

IVI 

S 

object  1 

M 

S 

changes 

M 

S 

At  least  one  entry  modification 

i' 

;  i 

'i 

must  be  supported. 

addAttribute 

0 

s 

rennoveAttribute  i 

0 

s 

addValues 

0 

s 

removeValues 

0 

s 

CommonArguments  i 

0 

s 

ModifyEntryResult  j 

s 

G 

ModifyRDN 

ModifyRDNArgument 

M 

S 

object 

M 

S 

newRDN 

M 

s 

.  deleteOldRDN 

0 

s 

CommonArguments 

0 

G 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

M  ori  ifvR  n  N  R  e<;u  it 

S 

G 

-  ERRORS  AND  PARAMETERS  - 

Abandoned 

AbandonFailed 

problem 

S 

M 

operation 

s 

M 

AttributeError 

object 

s 

M 

problems 

s 

M 

Min.  1  error(See  Directory 
Documents,  Part  3,  subclause 

type 

s 

M 

s 

G 

iNametrror 

s 

M 

matched 

o 
o 

M 

Referral 

candidate 

s 

G 

SecurityError 

problem 

s 

M 

ServiceError 

problem 

s 

M 

UpdateError 

problem 

s 

M  1 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

Protofu^l  Flpment 

ni  lA 

L/OAA 

1  II  1  lOI  HO 

MOaiTyriUNnesurt 

s 

G 

-  ERRORS  AND  PARAMETERS  - 

Abandoned 

AbandonFailed 

problem 

■  <; 

i' 

M 
IVl 

operation       .   ,  ,  , 

q 
o 

IVl 

AttributeError 

object 

o 
o 

M 

problems 

■  .1:  ,             ■■  :      '  ' 

Q 
O 

M 

Min.  1  error(See  Directory 
Documents,  Part  3,  subclause 
12.4.2.2) 

type 

M 

value 

;    i  ^ 

G 

NameError 

problem 

M 

matched 

i  S 

M 

Referral 

;  i 

candidate 

G 

SecurityError 

problem 

S 

M 

ServiceError 

problem 

s 

M 

UpdateError 

i 

problem 

S 

M 

I.; 
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Table  3  -  DAP  protocol  support  (continued) 


Protocol  Element 

Support  Classification 

Comments 

DUA 

DSA 

-  COMMON  ARGUMENTS  /  RESULTS  - 

CommonArguments 

ServiceControls 

0 

S 

SecurityParameters 

0 

S 

See  subclause  8.8. 

certification-path 

0 

S 

name 

0 

S 

time 

0 

S 

random 

0 

S 

target 

0 

S 

requestor 

0 

S 

OperationProgress 

0 

S  (0) 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

0 

s 

aliasedRDNs 

0 

S  (0) 

extensions 

0 

s 

identifier 

M 

s 

critical 

0 

s 

item 

M 

s 

CommonResults 

SecurityParameters 

0 

G(0) 

See  subclause  8.8. 

certification-path 

0 

G 

name 

0 

G 

time 

0 

G 

random 

0 

G 

target 

0 

G  [ 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

rioiocoi  uiemoni 

DUA 

DSA 

oommenis 

performer 

0 

G(0) 

aliasDereferenced 

0 

G 

-  COMMON  DATA  TYPES  - 

ServiceControls 

options 

0 

S 

priority 

0 

S 

timeLimit  .} 

0 

S 

sizeLimit 

0 

S 

scopeOfReferral 

0 

S 

EntrylnformationSeiection 

attributeTypes 

0 

S 

ailAttributes 

0 

s 

Must  support  at  least  one  of  the 
CHOICE. 

■,  V  select 

0 

S 

infoTypes 

0 

S 

Entrylnformation 

DistinguishedName 

S 

M 

fromEntry 

S 

G 

SET  OF  CHOICE 

S 

G 

AttributeType 

S 

G 

Attribute 

S 

G 

Filter 

Must  support  at  least  one  of  the 
CHOICE. 

item  ' 

0 

S 

and 

0 

S 

or 

0 

S 
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Table  3  -  DAP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

0 

S 

Filterltem 

0 

S 

0 

S 

M 

S 

oil  II  1^ w 

M 

S 

initidi 

0 

S 

Must  sunnort  at  lea"?t  one  of  the 
CHOICE. 

any 

0 

s 

final 

0 

s 

greaterOrEqual 

0 

s 

lessOrEqual 

U 

o 
o 

present 

0 

s 

approximateMatch 

U 

o 
o 

SecurityParameters 

o 

0 

See  subclause  8.8. 

certification-path 

U 

c 
o 

name 

U 

b 

time 

0 

s 

random 

0 

s 

target 

0 

s 

ContinuationReference 

targetObject 

0 

M 

aliasedRDNs 

0 

G 

OperationProgress 

0 

M 

nameResolutionPhase 

0 

M 

nextRDNToBeResolved 

0 

G 
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Table  3  -  DAP  protocol  support  (concluded) 


Support  Classification 

1  1  UlUUkJI  L.IOi  1  loi  IL 

UUA 

UoA 

V^(JI  1  If  1  lol  ilo 

rdnsResolved 

0 

G 

AccessPoint 

0 

M 

AccessPoint 

N3rn6 

0 

M 

PresentationAddress 

0 

M 

pSelector 

0 

G 

sSelector       ,  ■ 

0 

G 

tSelector 

0 

G 

nAddress 

0 

M 

NOTES 

1  As  performance  of  Search  and  List  operations  can  consume  significant  resources,  the 
policies  of  some  centralized  DSAs  may  be  that  such  operations  will  not  be  performed.  For 
these  cases,  the  reply  to  the  requests  for  such  operations  would  be  ServiceError  with  the 
"unwillingToPerform"  Service  Problem. 

2  See  EntrylnformationSelection  information  under  Common  Data  Types  (table  3,  part  6) 
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Table  4  -  Directory  system  service  support 


Support  Classification 

Operations  and  Errors 

Request 

Response 

Comments 

RINin  anrl  IIMRIMD  - 

UoADina 

n(notes  1,2) 

r 

DSAUnbind 

n(notes  1,2) 

r 

-  OPERATIONS  - 

-  CHAINED  READ 
UrhnA  1  lUNb  - 

ChainedRead 

n(notes  1,2) 

r 

ChainedCompare 

n(notes  1,2) 

r 

chainedAbandon 

n(note  1) 

r 

-  CHAINED  SEARCH 
nPFRATIDM"^  - 

n  (note  1) 

L>naincaoearcn 

n  (note  1) 

OPERATIONS  - 

ChainedAddEntry 

n  (note  1) 

ChainedRemoveEntry 

n  (note  1) 

ChainedEntry 

n  (note  1) 

ChainedModifyRDN 

n  (note  1) 

-  ERRORS  - 

Abandoned 

n(note  1) 

Abandonfailed 

n(note  1 ) 

AttributeError 

n(note  1) 

NameError 

n(note  1) 

DSARefferal 

n(note  1) 

SecurityError 

n(note  1) 

SeviceError 

n(note  1) 

UpdateError 

n(note  1) 

NOTES 

1  Necessary  when  supporting  the  chained  mode  of  interaction. 

2  Some  of  these  operations  may  be  necessary  to  support  distributed  authentication.  This 
requirement  is  distinct  from  support  for  chained  mode  of  interaction. 
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Table  5  ~  DSP  protocol  support 


Support  Classification 

Protocol  Element 

Comments 

-  biNU  and  undINU  - 

DSABInd 

DirectoryBlndArgument 

M 

s 

credentials 

G 

s 

simple 

G 

s 

name 

G 

s 

validity 

0 

0 

password 

G 

s 

strong 

1, 

0 

0 

See  Strong  Authentication 
Protocol  Conformance  Profile 
for  requirements  when  strong 
authentication  is  supported. 

externalProcedure 

0 

0 

versions 

G 

s 

Supported  value:  v1988 

DSABindResult 

S 

G 

credentials 

s  ■> 

G 

Shall  be  the  same  CHOICE 
as  in  DirectoryBindArgument. 

simple 

s 

G 

name 

s 

G 

validity 

i  0 

0 

password 

s 

G 

strong 

0 

1 

0 

See  Strong  Authentication 
Protocol  Conformance  Profile 
for  requirements  when  strong 
authentication  is  supported. 

externalProcedure 

\  0 

0 

versions 

s 

G 

Supported  value:  v1988 

DirectoryBindError 

s 

G 

versions 

s 

G 

Supported  value:  v1988 

ServiceProblem 

s 

G 

Supported  values:  busy  and 
unavailable. 

SecurityProblem 

s 

G 

Supported  values: 
inappropriate  Authentication, 
invalidCredentials. 

DSAUnbind 

The  DSAUnbind  has  no 
arguments. 
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Table  5  -  DSP  protocol  support  (continued) 


Protocol  Element 

Support  Classification 

Comments 

nequesi 

n6sponse 

-  OPERATIONS,  ARGUMENTS 

AND  RESULTS  - 

-  CHAINED  READ  OPERATIONS  - 

ChainedRead 

ChainingArgument 

M 

8 

ReadArgument 

M 

S 

object 

M 

S 

selection 

G 

8 

CommonArquments 

G 

S 

ChainingResult 

S 

M 

ReadResult 

S 

M 

entry 

S 

M 

CommonResults 

S 

G 

ChainedCompare 

ChainingArgument 

M 

8 

CompareArqument 

M 

8 

object 

M 

8 

purported 

M 

8 

CommonArguments 

G 

8 

ChainingResult 

S 

M 

CompareResult 

S 

M 

DistinguishedName 

S 

G 

matched 

S 

M 

from  Entry 

S 

G 

CommonResults 

S 

G 

ChainedAbandon 

AbandonArgument 

M 

8 

invokeld 

M 

8 

AbandonResult 

S 

G 

-  OPERATIONS,  ARGUMENTS  AND  RESULTS  - 

-  CHAINED  SEARCH 
OPERATIONS  - 

ChainedList 

ChainingArguments 

M 

8 

47 


Part  11  -  Directory  Services  Protocols  December  1991  (Stable) 

Table  5  -  DSP  protocol  support  (continued) 


Support  Classification 

V^k^l  1  II  1  1^1  HO 

Request 

Response 

ListArgument 

M 

S 

object 

M 

D 

CommonArguments 

G 

S 

ChainingResults 

S 

M 

ListResult 

8 

M 

listlnfo 

S 

G 

DistinguishedName 

S 

G 

subordinates 

S 

M 

'      Rel. DistinguishedName 

S 

M 

aliasEntry 

G 

fromEntry 

S 

G 

partialOutcomeQualifier 

S 

G 

CommonResults 

S 

G 

uncorrelatedLlstlnfo 

S 

G 

ListResult 

S 

G 

CiiainedSearch 

SearchArgument 

M 

S 

baseObject 

M 

S 

sugset 

G 

S 

filter 

G 

S 

searchAliases 

G 

S 

selection 

J 

G 

S 

CommonArguments 

G 

S 

ChainingResults 

S 

M 

SearchResult 

S 

M 

Searchinfo 

S 

M 

ni^tinni  li^hAHMjimp 

S 

G 

entries 

S 

M 

partialOutcomeQualifier 

S 

G 

CommonResults 

S 

G 

uncorrelatedSearchinfo 

S 

G 

SearchResult 

S 

G 

partialOutcomeQualifier 

S 

G 

limitProblem 

S 

G 
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Table  5  -  DSP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

Request 

Response 

Comments 

unexplored 

S 

G 

unavailableCriticalExt 

S 

G 

-  CHAINED  MODIFY 

ODPPATIOMQ 

\ji  idii  icuMuuci  III  y 

L»nainingMrgurTienis 

M 

S 

MaQcniryMr  yurneni 

M 

S 

ODjeci 

M 

S 

entry 

M 

S 

CommonArguments 

G 

S 

ChainingResults 

S 

M 

Muu  El  niry  n  es  u  its 

S 

M 

ChainedRemoveEntry 

v-^naininyMryurnenis 

M 

S 

n  e  rno  ve  c  niryMi  y  u  iTi  e  nt 

M 

S 

UUJcCl 

M 

S 

oui  1  iiiKJi  iMiyuiiici  llo 

G 

S 

ChainingResults 

S 

M 

RemoveEntryResult 

S 

M 

onaineaivioaiTytniry 

oriairiinyMry  umenis 

M 

S 

iviuuiiyci  III  yMi  yui  1  lol  11 

M 

S 

M 

S 

ui  idi  IUC70 

M 

S 

dUUMllI  lUUlc 

G 

S 

1  ol  1  l\JVcr\ul  lUUlo 

G 

s 

auU  V  dlU6S 

G 

S 

removeValues 

G 

S 

CommonArguments 

G 

S 

ChainingResults 

S 

M 

ModifyEntryResult 

S 

M 

ChainedModifyRDN 

ChainingArguments 

M 

S 

ModifyRDNArgument 

M 

S 

object 

M 

S 
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Table  5  -  DSP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

Request 

Response 

Comments 

newRDN 

M 

8 

deleteOldRDN 

G 

8 

CommonArguments 

G 

8 

ChainingResults 

8 

M 

ModifyRDNResult 

S 

M 

-  ERRORS  and  PARAMETERS  - 

Abandoned 

AbandonFailed 

problem 

S 

M 

operation 

8 

M 

AttributeError 

Min.1  error  (see  Directory 
Documents,  part  3, 
subclause  12.4.2.2) 

object 

,  8 

M 

problems 

8 

M 

problem 

8 

M 

type 

8 

M 

value 

8 

G 

NameError 

problem 

8 

M 

matched 

8 

M 

DSARefferal 

ContinuationReference 

s 

M 

contextPrefix 

s 

G 

SecurityError 

problem 

8 

M 

ServiceError 

8 

G 

For  Directory  operations 

problem 

8 

M 

UpdateError 

8 

G 

problem 

8 

M 

-  COMMON  ARGUMENTS  / 
RESULTS  - 

CommonArguments 

ServiceControls 

G 

8 

SecurityParameters 

0 

8 

see  subclause  8.8. 
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Table  5  -  DSP  protocol  support  (continued) 


Protocol  Element 

Support  Classification 

Comments 

Request 

Response 

requestor 

G 

s 

OperationProgress 

G 

s 

nameResolutionPhase 

M 

s 

nextRDNToBeResolved 

G 

s 

aliasedRDNs 

G 

s 

extensions 

G 

s 

identifier 

M 

s 

critical 

(3 

0 

0 

item 

M 

0 

s 

CommonResults 

SecurityParameters 

S 

0 

See  subclause  8.8. 

requestor 

s 

G 

aliasDereferenced 

s 

G 

-  COMMON  DATA  TYPES  - 

ServiceControls 

options 

G 

S 

priority 

(3 

timeLimit 

G 

sizeLimit 

r\ 
(3 

scopeOfReferral 

G 

S 

EntrylnformationSelection 

attributeTypes 

G 

0 

allAttributes 

G 

S 

select 

G 

S 

infoTypes 

G 

s 

Entrylnformation 

DistinguishedName 

s 

M 

fromEntry 

s 

G 

SET  OF  CHOICE 

s 

G 

AttributeType 

s 

G 

Attribute 

s 

G 

Filter 

item 

G 

S 

and 

G 

S 

or 

G 

S 

not 

G 

S 
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Table  5  -  DSP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

nequesi 

nesponse 

Comments 

Filterltem 

equality 

G 

8 

substrings 

^  G 

8 

type 

G 

8 

strings 

G 

s 

initial 

G 

8 

any 

G 

8 

final 

G 

8 

greaterOrEqual 

f  G 

8 

lessOrEqual 

G 

8 

present               '      •-  -■ 

?  i  G 

1 

S 

approximateMatch 

G 

8 

-  COMMON  DATA  TYPES  FOR 
DISTRIBUTED  OPERATION  - 

,.  (  ; 

i 

ChainingArguments 

originator 

'  G 

S 

targetObject 

;  G 

8 

operationProgress  > 

G 

8 

nanneResolutionPhase 

M 

8 

nextRDNToBeResolved 

G 

8 

tracelnformation 

M 

8 

aliasDereferenced  '■ 

'  G 

8 

aliasedRDNs 

G 

8 

returnCrossRefs 

i  G 

8 

See  Directory  Documents, 
Part  4,  subclause  10.4.1 

referenceType 

o 
o 

Domainlnfo 

I  0 

0 

timeLimit 

1  G 

8 

SecurityParameters 

i  0 

8 

See  note  1  regarding  the 
support  classification  for 
Request.  Also  see  subclause 
8.8 

ChainingResults 

Info 

0 

0 

crossReferences 

s 

G 
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Table  5  -  DSP  protocol  support  (continued) 


Support  Classification 

Protocol  Element 

Request 

Response 

Comments 

SecurityParameters 

S 

0 

See  note  1  regarding  the 
suppon  ciassiMCaiion  lor 
Response.  Also  see 
subclause  8.8 

CrossReference 

contextPrefix 

<! 
o 

See  Directory  Documents, 
Part  4,  subclause  12.4.2.2 

accessPoint 

s 

M 

Tracelnformation 

Traceltem 

M 

S 

Traceltem 

dsa 

M 

S 

targetObject 

G 

S 

operationProgress 

M 

S 

nameResolutionPhase 

M 

S 

nextRDNToBeResolved 

G 

S 

ContinuationReference 

targetObject 

S 

M 

aliasedRDNs 

S 

G 

OperationProgress 

S 

M 

nameResolutionPhase 

S 

M 

nextRDNToBeResolved 

S 

G 

ruiioncsoivcu 

S 

G 

referenceType 

S 

G 

AccessPoint 

S 

M 

AccessPoint 

Name 

S 

M 

PresentationAddress 

S 

M 

pSelector 

S 

G 

sSelector 

S 

G 
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Table  5  -  DSP  protocol  support  (concluded) 


Support  Classification 

Protocol  Element 

Request 

Response 

Comments 

tSelector 

S 

G 

nAddress 

S 

M 

NOTES 

1  The  support  classification  is  G  when  supporting  the  chained  mode  of  interaction. 

2  Some  of  these  operations  may  be  necessary  to  support  distributed  authentication.  This 

requirement  is  distinct  from  support  for  chained  mode  of  interaction. 

Table  6  -  DAP  Support  for  Digital  Signature  Protocol  Conformance  Profile. 


Protocol  Element 

Support  Classification 

Comments 

DUA 

DSA 

-  COMMON  ARGUMENTS  / 

RESULTS  - 

\  : 

CommonArguments 

1  - 

Secu  rityParam  eters 

certification-path 

\ 

S 

name  ; 

i.  ° 

S 

time 

i  G 

s 

random  ; 

■  1  ^ 

s 

target 

\  G 

s 

requestor 

!  G 

s 

CommonResults 

SecurityParameters 

'1 

S 

G 

performer 

S 

G 
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Table  7  -  DSP  support  for  digital  signature  protocol  conformance  profile 


Support  Classification 

Protocol  Element 

DUA 

DSA 

Comments 

-  COMMON  ARGUMENTS  /  RESULTS  - 

CommonArguments 

SecurityParameters 

certification-path 

G 

S 

name 

G 

S 

time 

G 

s 

random 

G 

s 

target 

G 

8 

requestor 

G 

S 

CommonResults 

SecurityParameters 

G 

S 

performer 

0 

G 
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Table  8  -  DAP  support  for  strong  authentication  protocol  conformance  profile 


Protocol  Element 

Support  Classification 

Comments 

DUA 

DSA 

DirectoryBindArgument 

M 

S 

credentials 

G 

S 

simple 

G 

S 

name 

G 

S 

validity 

G 

s 

password 

G 

s 

strong 

certification-path 

G 

s 

bind-token 

G 

s 

I  externalProcedure 

0 

0 

versions 

0 

s 

DirectoryBindResult 

S 

G 

credentials 

S 

G 

simple 

S 

G 

name 

S 

G 

validity 

S 

G 

passw/ord 

S 

G 

strong 

S 

G 

certification-path 

S 

G 

bind-token 

S 

G 

externalProcedure 

0 

0 

versions 

s 

0 
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Table  9  -  DSP  support  for  strong  authentication  protocol  conformance  profile 


Protocol  Element 

Support  Classification 

Comments 

DUA 

DSA 

DirectoryBindArgument 

M 

S 

credentials 

G 

S 

simple 

G 

S 

name 

G 

s 

validity 

G 

s 

password 

G 

s 

strong 

certification-path 

G 

s 

bind-token 

G 

s 

externalProcedure 

0 

0 

versions 

0 

s 

DirectoryBindResult 

S 

G 

credentials 

S 

G 

simple 

o 
o 

/-> 

name 

S 

G 

validity 

s 

G 

password 

s 

G 

strong 

s 

G 

certification-path 

s 

G 

bind-token 

s 

G 

externalProcedure 

0 

0 

versions 

s 

0 
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Table  10  -  Error  symptoms 


Symptom 

Description 

EACCESS 

The  initiator  has  insufficient  access  rights  to  carry  out  this  operation. 

E  ADMIN  LIMIT 

The  Directory  has  reached  some  limit  set  by  an  administrative  authority, 
and  no  partial  results  are  available  to  return  to  the  user. 

E_ALIAS_DEREF 

One  of  three  situations  exists: 

1  An    alias    has    been    encountered    while  a 
previous  alias  was  being  dereferenced,  or 

2  a  name  contained  an  alias  plus  one  or  more 
additional                     RDNs        when  the 

used,  or 

3       the    name,    supplied    in    an    operation  that 
precludes   alias         dereferencing,    contained  an 
alias  plus  one  or  more  additional  RDNs. 

E_ALIAS_LOOP 

During  a  whole-subtree  search  operation,  an 
alias  has  been  encountered  which  would  lead  to 
a  loop  (i.e.,  the  alias  points  to  an  entry 
which  is  superior  to  entries  which  have 
already  been  evaluated  in  carrying  out  the 
search) . 

E_ALIAS_PROBLEM 

An  alias  has  been  encountered,  but  the  entry  to 
which  it  points  does  not  exist. 

E_ARG_BOUNDS 

The  argument  does  not  comply  with  pragmatic 
constraints  (defined  locally  or  by  functional 
standards ) . 
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Table  10  -  Error  symptoms  (continued) 


Symptom 

Description 

E_ARG_SYNTAX 

An  operation  argument  either  has  incorrect 
ASN.l  encoding  or  correct  ASN.l  encoding,  but 
does  not  comply  to  the  syntax  as  defined  in  the 
Directory  Documents. 

NOTES 

1  Within  BindArgument,  additional  elements  are  permitted,  to 
allow  future  extensions,  and  do  not  create  an  error  situation. 

2  Errors  within  attribute  values  are  not  included  in  this 
codification  (see  E  ATT  SYNTAX). 

E_ARG_VIOL 

An  operation  argument  has  correct  syntax,  but 
it  violates  additional  rules  and  constraints 
levied  by  the  Directory  Documents  (e.g.,  use  of 
a  Priority  integer  value  whose      meaning  is 
undefined) . 

NOTES 

1  Within  a  Relative  Distinguished  Name,  having  two  AVAs  of 
the  same  attribute  type  is  an  error  which  is  covered  by 

E  DN,  and  not  by  E  ARG  VIOL. 

2  Errors  within  attribute  values  are  not  included  in  this 

nciHifir-atli-in  /coo  P  ATT  ^;VMTAY^ 

E_ATT_BOUNDS 

An  attribute  value  does  not  comply  with  bounds 
specified  either  by  the  Directory  Documents  or 
by  functional  standards. 

E_ATT_OR_VALUE_EXI STS 

Within  an  entry,  an  attribute  or  attribute 
value  already  exists,  causing  an  error 
situation. 

E_ATT_SYNTAX 

An  attribute  value  either  has  incorrect  ASN.l 
encoding  or  it  has  correct  ASN.l  encoding  but 
does  not  comply  with  the  ASN.l  encoding  defined 
by  the  attribute  type. 

E_ATT_VALUE 

An  attribute  value,  although  of  correct  ASN.l 
encoding,  and  conformant  with  the  syntax 
defined  for  the  attribute  type,  is  not 
compliant  with  other  rules  (e.g.,  a  non-ISO 
3166  country  name  encoding). 

E_ACCESS 

The  initiator  has  insufficient  access  rights  to 
carry  out  this  operation. 

E_AUTHENT I CAT I ON 

The  authentication  offered  does  not  match  that 
required  by  the  object  being  authenticated. 
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Table  10  -  Error  symptoms  (continued) 


Symptom 

Description 

EBUSY 

The  DSA  is  unable  to  handle  this  operation  at  this  time  (but  it  may  be 
able  to  do  so  after  a  short  while). 

ECANTCONSTRUCT 

The  update  to  be  transmitted  exceeds  a  local  size  limit. 

F  TANT  INrnRPDRATF 

THa  I  ir^H?itP  rflr^AiwAH  ovr*AAH<5  9  li^^^al  APPil  1  qitp  limit 

F  CHAIN 

Thfl  n^A  haaHq  tri  ii^a  ^^h^4inin^  tn  r^rrv  niit  thiQ  nnAratinn  hut  ic 
1  1 17  UKjr^  I i\j  uoo      iciii  ill  1^  iw  v^cii  1  y  wui  ii  iio  sjlj^i  cili^i  ||  kjui  lo 

prohibited  from  doing  so  by  Service  Controls. 

ECREDENTIALS 

The  credentials  offered  do  not  match  those  of  the  object  with  which 
authentication  is  taking  place. 

EDBE 

An  inconsistency  has  been  detected  in  the  DSA's  data  base,  which  may 
be  localized  to  a  particular  entry  or  set  of  entries. 

EDITSTRUCTURE 

An  attempt  was  made  via  an  add  operation  to  place  an  entry  in  the  DIB 
whose  object  class  would  violate  the  DIT  structure  rules. 

EDN 

A  DN  contains  an  RDN  with  two  AVAs  of  the  same  attribute  type. 

E  DSA 

A  DSA  to  which  chaining  is  taking  place  is  unable  to  respond. 

F  FMTRY  Fyi<^T<? 

r\i  \  duly  \J\  IWfs  UlVCf  1  t  Icil  lie;  ctllc^dUy  CAIoLo,  v^dUoll  IM  dl  1  cl  i  vJI . 

E  EXTENSION 

A  DSA  wa<;  unahls  to  <?ati'^f\/  a  rsousst  because  one  or  more  critiral 
extensions  were  not  available. 

E  ILLEGAL  ROOT  OBJ 

Root's  DN  has  been  supplied  as  the  object  of  a  Read,  Compare, 
AddEntry,  RemoveEntry,  ModifyEntry,  ModifyRDN,  or  as  the  Base 
Object  of  a  single  level  search. 

EJLLEGALROOTVAL 

Root's  DN  has  been  supplied  illegally  as  an  attribute  value  (eg.,  as  an 
Aliased  Object  Name). 

EJNACTIVEAGREEMENT 

The  specified  is  not  currently  active. 

E  INVALID  AGREEMENT 

A  valid  agreement  does  not  exist  with  the  DSA. 

F  LOOP 

A  Innn  ha";  hpfn  HptprtpH  in  the  knowlpdnp  information  within  the 

/a              I  icio  u^^i  1  u^ic^l^u  II  1  11  1^  r\i  iwvvi^uu^  ii  iiwi  1 1  icaiiv.'i  i  vviii  iii  i  ii 

system. 

EMATCH 

The  attribute  specified  does  not  support  the  required  matching 
canahilitv 

E  MISSED  PREVIOUS 

The  value  received  in  lastUpdate  or  is  not  consistent  with  the  time  the 
recipient  DSA  understands  was  the  time  of  the  last  update. 

E  MISSING  AVA 

When  creating,  or  after  modifying,  an  entry,  an  AVA  in  the  entry's  RDN 
is  not  represented  within  the  entry's  set  of  attributes. 

EMISSINGOBJECTCLASS 

When  creating  an  entry,  the  entry  does  not  possess  an  object  class. 

E_MORE_CURR_UPD_RCD 

A  consumer  DSA  processing  supplier-initiated  updates  determines  that 
the  update  the  supplier  is  attempting  to  send  is  older  than  one  the 
consumer  has  already  received. 

EMULTIDSA 

The  operation  is  an  update  operation  which  affects  other  DSAs. 

ENAMINGVIOUVTION 

The  name  of  the  new  or  modified  entry  is  incompatible  with  its  object 
class. 

ENOAGMTWTHISDSA 

The  receiving  DSA  has  no  agreements  in  place  with  the  sending  DSA. 

60 


Part  11  -  Directory  Services  Protocols  December  1991  (Stable) 


Table  10  -  Error  symptoms  (continued) 


Symptom 

Description 

E_NON_LEAF_OPERAT I ON 

The  operation  being  attempted  is  illegal  except 
on  a  leaf. 

E_NONNAMING_ATTRIBUTE 

In  either  an  add  or  ModifyRDN  operation,  an 
attribute  is  included  in  the  last  RDN  that  is 
not  a  valid  naming  attribute  according  to  the 

E_NOT_S I NGLE_VALUED 

An  attribute,  registered  as  single-valued,  has 
been  found  with  more  than  one  value. 

E  NO  SUCH  ATT 

The  specified  attribute  has  not  been  found. 

E  NO  SUCH  OBJECT 

The  specified  entry  has  not  been  found. 

E_NO_SUCH_VALUE 

The  specified  attribute  value  has  not  been 
found. 

E_OBJECT_CLASS_MOD 

An  (illegal)  attempt  has  been  made  to  alter  or 
remove  an  object  class  attribute. 

E_OBJECT_CLASS_VIOL 

There  is  a  schema  violation  (e.g.,  missing 
mandatory  attribute,  or  non-allowed  attribute 
present ) . 

E_PREVI OUSLY_COORD 

A  supplier  DSA,  while  processing  consumer- 

■iT^i+"a4-^/^    iiT>^a4"oe       Vise     ko/^^itt^/^  3 
lIllvClLt^U    UpUciUco  ,     lids    LcOt^lVcU  d 

coordinateShadowUpdate  referring  to  a  shadow 
agreement  for  which  a  previous 
coordinateShadowUpdate  has  already  been 
received  and  is  still  outstanding. 

E_PREVI OUS  L Y_S OLICITED 

A  supplier  DSA,  while  processing  consumer- 
initated  updates,  has  received  a 
requestShadowUpdate  referring  to  a  shadow 
agreement  for  which  a  previous 
requestShadowUpdate  has  already  been  received 
and  is  still  outstanding. 

E_REFERENCE 

An  erroneous  reference  has  been  detected  (e.g., 
DSA  cannot  handle  name  even  as  far  as  the 
number  of  RDNs  that  have  already  been 
resolved) . 

No  referrals  were  available  within  the 
requested  scope. 

E_SYSTEM_PERM 

A  serious  and  permanent  software  or  system 
error  has  been  detected  which  prevents 
completion  of  the  operation. 

E_SYSTEM_TEMP 

A  serious  but  temporary  software  or  system 
error  has  been  detected  which  prevents 
completion  of  the  operation. 

E_TIMEOUT 

The  operation  has  not  completed  within  the 
allotted  time. 

E_T I MESTAMP_MI SMATCH 

An  unrecoverable  timestamp  mismatch  has  been 
detected. 
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Table  10  -  Error  symptoms  (continued) 


Symptom 

Description 

E_UNABLE_TO_COMPLETE 

The  DSA  is  unable  to  complete  this  operation, 
or  others  like  it  (this  applies  particularly  to 
search) . 

E_UNABLE_TO_PROCEED 

The  DSA  cannot  satisfy  the  operation  after 
receiving  iz  on  tne  oasis  or  a  vaiia 
non-specific  subordinate  reference. 

£«  UNCUUKD 1 W  A 1  £iU 

A  consumer  DSA,  while  processing  supplier— 
initated  updates,  has  received  an  updateShadow 
request  for  which  there  is  no  outstanding 
coordinateShadowUpdate . 

E_TOO_MANY_UPDATES 

Supplier  DSA  determines  that  there  are  too  many 
updates  for  incremental  refresh  and  that  a  full 
update  is  required. 

E_UNDEFINED_ATT 

An  unregistered  attribute  has  been  encountered. 

E_UNREL I ABLE_DATA 

A  DSA  has  detected  internal  data 
i  neons  i  s  t  enc i e  s . 

E_UNSOLICITED 

A  consumer  DSA,  while  processing  consumer- 
initated  updates,  has  received  an  updateShadow 
for  which  there  is  no  outstanding 
requestShadowUpdate . 

E_UNSUPPORTED_OC 

The  object  class  of  the  entry  is  not  supported 
as  a  valid  object  class  for  entries  within  this 
DSA. 

E_UNSUPPORTED_STRAT 

The  refresh  strategy  selected  is  not  supported 
by  this  DSA. 

E_UNUSABLE_DATA 

A  consumer  DSA  has  decided  that  the  received 
data  is  completely  unusable  due  to  error. 

E_VERSION 

An  unexpected  version  has  been  found  in  Bind. 

E_ZERO_VALUES 

An  attribute  has  been  found  (e.g.,  as  a  result 
of  a  modify-entry  operation)  with  no  values. 
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Table  1 1  -  Error  situations 


Situation 

Description 

ABANDON 

An  Abandon  operation  is  being  carried  out. 

ADD-ENTRY 

The  entry  is  being  generated. 

 :  

ADD-ENTRY-NAME-RESOLUTION 

 —  

During  an  add  entry  operation,  name  resolution  has  been 
successfully  accomplished  on  the  superior  object,  and  is  not  being 
carried  out  to  determine  whether  the  new  entry  already  exists. 

dINU-LUCAL 

A  bind  is  being  attempted;  either  the  entry  named  is  (or  should  be) 
within  a  local  naming  context,  or  name  resolution  is  being  carried 
out  on  the  part  of  the  name  that  is  known  locally. 

BIND-REMOTE 

A  bind  is  being  attempted,  and  the  entry  named  is  not  within  a  local 
naming  context;  remote  validation  of  credentials  is  being  carried 
out. 

COMPARE 

A  Compare  operation  is  being  carried  out  on  the  entry. 

COORDINATE-SHADOW-UPDATE 

The  shadow  consumer  has  received  a  coordinateShadowUpdate 
from  the  supplier  DSA  and  is  evaluating  its  contents. 

LIST 

A  List  ooeration  i"?  bpinn  carried  out  on  the  entrv 

MODIFY-ENTRY 

The  entry  is  being  modified. 

MODIFY-RDN 

The  RDN  is  being  modified. 

NAME-RESOLUTION 

Name  resolution  is  being  carried  out. 

READ 

The  entry  is  being  read. 

REMOVE-ENTRY 

The  entry  is  being  removed. 

REQUEST-SHADOW-UPDATE 

The  supplier  DSA  is  processing  a  RequestShadowUpdate  received 
from  a  consumer. 

REQUEST-SHADOW-UPDATE- 

I~» ^C*  1  II  "T" 

RESULT 

The  consumer  DSA  has  received  a  reply  to  a  request  for  update. 

SEARCH-ENTRY 

A  Search  operation  is  being  carried  out;  the  required  entry 
information  is  being  evaluated  or  acted  upon. 

SEARCH-FILTER 

A  Search  operation  is  being  carried  out;  the  filter  is  being  evaluated 
or  acted  upon. 

TRACE-EVALUATION 

The  trace  element  is  being  evaluated  for  loops. 

UPDATE-SHADOW 

The  consumer  DSA  has  received  an  UpdateShadow  from  the 
supplier  and  is  trying  to  incorporate  the  updated  information. 
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Table  12  -  Notation  used  to  describe  error  actions. 


Error  Action  Notation 

Meaning 

Rej 

A  reject  operation  is  generated,  with  problem  mistyped-argument. 

Ab(<  qualifier  >) 

Abandon  Failed  Error  is  generated.  The  qualifier  may  take  on  values  codified 
as  follows: 

CA  -  Cannot  abandon 

NSO  -  No  such  operation 

TL  -  Too  late 

A(<  qualifier  >) 

Attribute  Error  is  generated.  The  qualifier  may  take  on  values  codified  as 
follows: 

AVE  -  Attribute  or  value  already  exists 

CV  -  Constraint  violation 

IAS  -  Invalid  attribute  syntax 

IM  -  Inappropriate  matching 

NSA  -  No  such  attribute 

UAT  -  Undefined  attribute  type 

N(<quaiifier>) 

NameError  is  generated.  The  qualifier  may  take  on  values  codified  as  follows: 
ADP  -  Alias  dereferencing  problem 
AP  -  Alias  problem 
IAS  -  Invalid  attribute  syntax 
NSO  -  No  such  object 

SH(<qualifier>) 

Shadow  Error  is  generated.  The  qualifier  may  take  on  values  codified  as 
follows: 
lAID  -  Invalid  Agreement  ID 
lA   -  Inactive  Agreement 
IIR  -  Invalid  information  received 

IS      -  Invalid  Sequencing 
US      -  Unsupported  strategy 

MP      -  Missed  previous 
FUR    -  Full  update  required 
UWP    -  Unwilling  to  perform 
UT      -  Unsuitable  timing 
UAR    -  Update  already  received 

SC(<qualif ier>) 

Security  Error  is  generated.  The  qualifier  may  take 
on  values  codified  as  follows: 

lA    -    Inappropriate  authentication 

lAR  -  Insufficient  access  rights 

IC    -    Invalid  credentials 

IS    -    Invalid  signature 

NI    -    No  information 

PR    -    Protection  required 
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Table  12  -  Notation  used  to  describe  error  actions,  (concluded) 


Error  Action  Notation 

Meaning 

S(<  qualifier  >) 

Service  Error  is  generated.  The  qualifier  may  take  on  values  codified  as 

follows: 

ALE  -  Administrative  limit  exceeded 

B   -  Busy 

CR  -  Chaining  required 

DE  -  Dit  Error 

IR  -  Invalid  reference 

LD  -  Loop  detected 

OOS  -  Out  of  Scope 

TLE  -  Time  limit  exceeded 

UA  -  Unavailable 

UAP  -  Unable  to  proceed 

UCE  -  Unavailable  critical  extension 

UWP  -  Unwilling  to  perform 

U(<  qualifier  >) 

Update  Error  is  generated.  The  qualifier  may  take  on  values  codified  as 
follows: 

AMD    -  Affects  multiple 

DSAEAE  -  Entry  already  exist 

NAN     -  Not  allowed  on  non-leaf 

NAR     -  Not  allowed  on  RDN 

NV     -  Naming  violation 

OCV    -  Object  class  violation 

OMP    -  Object  class  modification  prohibited 
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Symptom 
(See  Table  10) 

Situation  (See  Table  11) 

Bind- 
Local 

Bind- 
Re  mote- 
Resolution 

Name- 
Resolution 

Add-Entry- 

Name- 

Resolution 

Add-Entry 

Modify- 
Entry 

E  ACCESS 

SC(IAR) 
(14) 

SC(IAR) 
(14) 

SC(IAR) 
(14) 

SC(1AR)(14) 

E_ADMIN_L!MIT 

S(UA) 

S(UA) 

S(ALE) 

S(ALE) 

S(ALE) 

S(ALE) 

E  ALIAS  DEREF 

S(IC) 

S(IC) 

N(ADP) 

E  ALIAS  LOOP 

EALIASPROBLEM 

S(IC) 

S(IC) 

N(AP) 

EARGBOUNDS 

(8) 

(7) 

S(UWP) 
(12) 

S(UWP) 
(12) 

S(UWP) 
(12) 

S(UWP)(12) 

EARGSYNTAX 

(1) 

(1) 

Rej 

Rej 

Rej 

Rej 

EARGVIOL 

(1) 

(1) 

Rej 

Rej 

Rej 

Rej 

EATTBOUNDS 

SC(IC) 

(7) 

N(IAS) 
(15,  16) 

N(IAS) 
(15,  16) 

A(CV) 

A(CV) 

E  ATT  OR  VALUE  EXISTS 

A(AVE) 

A(AVE) 

E  ATT  SYNTAX 

SC(IC) 

(7) 

N(IAS) 
(15,  16) 

N(IAS) 
(15,  16) 

A(IAS) 

A(IAS) 

EATTVALUE 

SC(IC) 

(7) 

N(IAS) 
(15,  16) 

N(IAS) 
(15,  16) 

A(IAS) 

A(IAS) 

EAUTHENTICATION 

SC(IA) 

SC(IA) 

EBUSY 

S(UA) 

S(UA) 

S(B) 

S(B) 

S(B) 

S(B) 

b  L.AN  1  LUNolHUL'l 

ECANTJNCORPORATE 

ECHAIN 

S(CR) 

ECREDENTIALS 

SC(IC) 

SC(IC) 

EDBE 

S(UA) 

S(UA) 

S(DE) 

S(DE) 

S(DE) 

S(DE) 

EDITSTRUCTURE 

U(NV) 

EDN 

SC(IC) 

SC(IC) 

N(NSO) 

C(NV) 

EDSA 

S(UA) 

S(UA) 

S(UA) 
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Table  13  -  Error  actions  (continued) 


Symptom 
(See  Table  10) 

Situation  (See  Table  11) 

Bind- 
Local 

Bind- 

Remote- 

Resolution 

Name- 
Resolution 

Add-Entry- 

Name- 

Resolution 

Add-Entry 

Modify- 
Entry 

L  tN  1  HY  bXlolo 

U(EAE) 

E  EXTENSION 

S(UWP) 

S(UCE) 

S(UCE) 

S(UCE) 

r-    II  1  CO  A 1     D/^/^X    r\D  1 

t  ILLbOaAL  nUUI  UbJ 

SC(IC) 

SC(IC) 

N(NSO) 

N(NSO) 

N(NSO) 

E  ILLEGAL  ROOT  VAL 

SC(IC) 

(7) 

N(IAS) 
(15,  16) 

N(IAS) 

/AC      1  C\ 

(15,  16) 

A(IAS) 

A(IAS) 

EJNACTIVEAGREEMENT 

EJNVALIDAGREEMENT 

ELOOP 

C/l  IA\ 

o(UA) 

b(LU) 

EMATCH 

00(10) 

oO(IO) 

A(IM) 

A(IM) 

A(1M) 

EMISSEDPREVIOUS 

EMISSINGAVA 

EMISSINGOBJECTCLASS 

EMORECURRUPDRCD 

EMULTIDSA 

\J\r\W\U) 

ENAMINGVIOLATIGN 

ENOAGMTWTHISDSA 

ENOENTRIESJNST 

ENONLEAFOPERATION 

ENONNAMINGATTRIBUTE 

U(NV) 

E  NOT  SINGLE  VALUED 

A(CV) 

A(CV) 

ENOSUCHATT 

A(NSA) 

ENOSUCHOBJECT 

SC(IC) 

SC(IC) 

N(NSO) 

ENOSUCHVALUE 

A(NSA) 

EOBJECTCLASSMOD 

U(OMP) 

EOBJECTCLASSVIOL 

U(OCV) 

U(OCV) 

EOUTSIDEUOR 
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Symptom 
(See  Table  10) 

Situation  (See  Table  1 1 ) 

Bind- 
Local 

Bind- 

Resolution 

Name- 

RaqoIi  itinn 

Add-Entry- 

Name- 

Resolution 

Add-Entry 

hA  nr\  ifv/- 
iviuvjii  y 

Entry 

EPREVIOUSLYCOORD 

EREFERENCE 

S(UA) 

S(IR)  (17) 

ESCOPE 

S(OOS) 

EPREVIOUSLYSOLICITED 

ESYSTEMPERM 

S(UA) 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

ESYSTEMTEMP 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

ETIMEOUT 

S(UA) 

(9) 

S(TLE) 

S(TLE) 

S(TLE) 

S(TLE) 

ETIMESTAMPMISMATCH 

ETOOM  AN  Y_U  PD  ATES 

EUNABLETOCOMPLETE 

E_UNABLE_TO_PROCEED 

(2) 

(2) 

EUNCOORDINATED 

EUNDEFINEDATT 

SC(IC) 

(3) 

U(NV) 

A(UAT) 

A(UAT) 

EUNRELIABLEDATA 

EUNSOLICITED 

EUNSUPPORTEDOC 

U(OCV) 

EUNSUPPORTEDSTRAT 

EUNUSABLEDATA 

EVERSION 

S(UA) 

EZEROVALUES 

A(CV) 

A(CV) 
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Symptom  (See  Table  10) 

Situation  (See  Table  11) 

MOQIiy-nUIN 

Remove-Entry 

neaa 

Compare 

Trace- 
Evalu- 
ation 

EACCESS 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAR)(14) 

SC(IAR)(14) 

EADMINLIMIT 

S(ALE) 

S(ALE) 

S(ALE) 

EALIASDEREF 

E  ALIAS  LOOP 

EALIASPROBLEM 

 ^  — 

E  ARG  BOUNDS 

EARGSYNTAX 

Rej 

Rej 

Rej 

Rej 

Rej 

EARGVIOL 

Rej 

Rej 

Rej 

Rej 

Rej 

EATTBOUNDS 

N(IAS) 

A(CV) 

EATTORVALUEEXISTS 

 ^  ™  

EATTSYNTAX 

N(IAS) 

A(IAS) 

(7) 

EATTVALUE 

N(IAS) 

A(IAS) 

(7) 

EAUTHENTICATION 

EBUSY 

S(B) 

S(B) 

S(B) 

S(B) 

ECANTCONSTRUCT 

ECANTJNCORPORATE 

ECHAIN 

ECREDENTIALS 

EDBE 

S(DE) 

S(DE) 

S(DE) 

S(DE) 

EDITSTRUCTURE 

EDN 

A(CV) 

A(IAS) 

EDSA 
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Symptom  (See  Table  10) 

Situation  (See  Table  11) 

Modify-RDN 

Remove-Entry 

Read 

Compare 

Trace- 
Evaluation 

EENTRYEXISTS 

U(EAE) 

EEXTENSION 

S(UCE) 

S(UCE) 

S(UCE) 

S(UCE) 

EJLLEGALROOTOBJ 

N(NSO) 

N(NSO) 

N(NSO) 

N(NSO) 

EJLLEGALROOTVAL 

N(IAS) 

A(IAS) 

(7) 

EJNACTIVEAGREEMENT 

EJNVALIDAGREEMENT 

ELOOP 

EMATCH 

A(IM) 

A(IM) 

(7) 

EMISSEDPREVIOUS 

EMISSINGAVA 

EMISSINGOBJECTCLASS 

EMORECURRUPDRCD 

EMULTIDSA 

U(AMD) 

U(AMD) 

ENAMINGVIOLATION 

U(NV) 

ENOAGMTWTHISDSA 

ENOENTRIESJNST 

ENONLEAFOPERATION 

U(NAN) 

U(NAN) 

ENONNAMINGATTRIBUTE 

b  NU 1  oINQaLb  VALUcU 

A(CV) 

ENOSUCHATT 

A(NSA)(4) 

A(NSA)(4) 

ENOSUCHOBJECT 

ENOSUCHVALUE 

EOBJECTCLASSMOD 

EOBJECTCLASSVIOL 

U(OCV) 

EOUTSIDEUOR 
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Symptom  (See  Table  10) 

Situation  (See  Table  11) 

Modify-RDN 

Remove-Entry 

Read 

Compare 

Trace- 
Evaluation 

F  RFFFRFMPF 

F  DDF\/ini  IQI  V  <ini  IPITFn 

F  QYQTFM  PFRM 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

S(UWP) 

F  QVQTF^yl  TFMP 
C  oTOICm    1  ClVIr 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

S(UA) 

F  TIR/IFHI  IT 

S(TLE) 

S(TLE) 

S(TLE) 

S(TLE) 

C    1  IIVIuCS  1  MMr    MIOIVIM  1  C>n 

F  THO  MAMV  1  IPDATFQ 

F  1  IMARI  F  TH  POMPI  FTF 

F  1  IMARI  F  TO  PROPFFn 

F  1  iMPnnRniMATFn 

EUNDEFINEDATT 

A(UAT) 

1  A(NSA)(4) 

A(NSA) 

(7) 

EUNRELIABLEDATA 

EUNSOLICITED 

EUNSUPPORTEDOC 

EUNSUPPORTEDSTRAT 

EUMUSABLEDATA 

EVERSION 

EZEROVALUES 

(11) 
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Symptom  (See  Table  10) 

Situation  (See  Table  1 1 ) 

List  (Filter) 

Search  (Filter) 

Search  Entry 

Abandon 

EACCESS 

EADMINLIMIT 

Q/AI  P\/1  'i\ 

EALIASDEREF 

(a; 

EALIASLOOP 

EALIASPROBLEM 

EARGBOUNDS 

Q/i  |\A/D\H  0\ 

O/l  |\A/D\/1  0\ 

EARGSYNTAX 

Pa! 

Poi 

Pal 

nej 

Poi 
nej 

EARGVIOL 

Pol 

Doi 

nej 

Pai 

EATTBOUNDS 

E_ATT_OR_VALUE_EXISTS 

E_ATT_SYNTAX 

EATTVALUE 

 ^  

A(IAS) 

EAUTHENTICATION 

EBUSY 

S(B) 

S(B) 

S(B) 

ECANTCONSTRUCT 

ECANTJNCORPORATE 

ECHAIN 

ECREDENTIALS 

EDBE 

S(DE) 

S(DE) 

S(DE) 

EDITSTRUCTURE 

EDN 

A(IAS) 

EDSA 

(5) 
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Symptom  (See  Table  10) 

Situation  (See  Table  11) 

List  (Filter) 

Search  (Filter) 

Search  Entry 

Abandon 

EENTRYEXISTS 

EEXTENSION 

S(UCE)(13) 

S(UCE)(13) 

S(UCE)(13) 

EJLLEGALROOTOBJ 

(10) 

EJLLEGALROOTVAL 

A(IAS) 

EJNACTIVEAGREEMENT 

EJNVALIDAGREEMENT 

ELOOP 

(5) 

EMATCH 

A(IM) 

EMISSEDPREVIOUS 

EMISSINGAVA 

EMISSINGOBJECTCLASS 

EMORECURRUPDRCD 

EMULTIDSA 

ENAMINGVIOLATION 

ENOAGMTWTHISDSA 

E_NO_ENTRIESJN_ST 

E  NON  LEAF  OPERATION 

ENONNAMINGATTRIBUTE 

E  NOT  SINGLE  VALUED 

ENOSUCHATT 

ENOSUCHOBJECT 

ENOSUCHVALUE 

EOBJECTCLASSMOD 

E  OBJECT  CLASS  VIOL 

EOUTSIDEUOR 
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Situation  (See  Table  11) 

LIST  ^rilTQiy 

oearcn  ^riiisr; 

oearcn  tniry 

Absndon 

E  PREVIOUSLY  COORD 

E  REFERENCE 

 _____  . 

ESCOPE 

 —  ^  

EPREVIOUSLYSOLICITED 

ESYSTEMPERM 

o  /I  11 A  /ri\ 

b(UWP) 

c* /I  i\ A /n\ 

S(UWP) 

b(uWP) 

Ab(CA) 

ESYSTEMTEMP 

O /I  1  A  \ 

S(UA) 

O  /H  1  A  \ 

S(UA) 

O /I  1  A  \ 

S(UA) 

A  L>         A  \ 

Ab(CA) 

ETIMEOUT 

S(TLE)(13) 

S(TLE)(13) 

S(TLE)(13) 

ETIMESTAMPMISMATCH 

E  TOO  MANY  UPDATES 

E  UNABLE  TO  COMPLETE 

(B) 

S(B) 

S(B) 

Ab(CA) 

F  1 IMARI  F  TO  PROPFFn 

F  uMcnnRniNATFn 

EUNDEFINEDATT 

(6) 

(6) 

EUNRELIABLEDATA 

EUNSOLICITED 

EUNSUPPORTEDOC 

EUNSUPPORTEDSTRAT 

EUNUSABLEDATA 

EVERSION 

EZEROVALUES 
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Table  13  -  Error  actions  (continued) 


Symptom  (See  Table  10) 

Situation  (See  Table  11) 

Coordinate 
Shadow 

Update 
Shadow 

Request 
Shadow 

U  [JUciLt? 

EACCESS 

EADMINLIMIT 

EALiASDEREF 

EALIASLOOP 

EALIASPROBLEM 

EARGBOUNDS 

EARGSYNTAX 

EARGVIOL 

EATTBOUNDS 

EATTORVALUEEXISTS 

EATTSYNTAX 

EATTVALUE 

EAUTHENTICATION 

EBUSY 

SH(UT) 

SH(UT) 

SH(UT) 

ECANTCONSTRUCT 

SH(UWP) 

ECANTJNCORPORATE 

SH(UWP) 

ECHAIN 

ECREDENTIALS 

EDBE 

EDITSTRUCTURE 

EDN 

EDSA 
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Symptom  (See  Table  10) 

Situation  (See  Table  11) 

Coordinate 

Shadow 

Update 

Update 
Shadow 

Request 
Shadow 
Update 

EENTRYEXISTS 

 , — , — _ 

EEXTENSION 

EJLLEGALROOTOBJ 

EJLLEGALROOTVAL 

EJNACTIVEAGREEMENT 

SH(IA) 

SH(IA) 

SH(IA) 

EJNVALIDAGREEMENT 

SHflAID^ 

SHMAID^ 

III*   il  f 

SHflAID^ 

ELOOP 

EMATCH 

EMISSEDPREVIOUS 

SHfMP^ 

SH^MP\ 

\J  1  IIIVII  1 

EMISSINGAVA 

E_MISS1NG_0BJECT_CL^SS 

EMORECURRUPDRCD 

SH(UAR) 

EMULTIDSA 

ENAMINGVIOLATION 

ENOAGMTWTHiSDSA 

SH(IAID) 

SH(IAID) 

SH(IAID) 

ENOENTRIESJNST 

SH(NI) 

ENONLEAFOPERATION 

ENONNAMINGATTRIBUTE 

ENOTSINGLEVALUED 

ENOSUCHATT 

SH(IIR) 

ENOSUCHOBJECT 

SH(IIR) 

ENOSUCHVALUE 

EOBJECTCLASSMOD 

EOBJECTCLASSVIOL 

EOUTSIDEUOR 

SH(IIR) 
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Symptom  (See  Table  1 0) 

Situation  (See  Table  11) 

Coordinate 

Shadow 

Update 

Update 
Shadow 

Request 
Shadow 
Update 

E  PREVIOUSLY  COORD 

OLJ/IO\ 

SH(IS) 

EREFERENCE 

 . — . — . — .  

E  SCOPE 

 .  

E  PREVIOUSLY  SOLICITED 

ESYSTEMPERM 

cwnjWP^ 

ESYSTEMTEMP 

on^u  1  f 

OHM  JT^ 

ETIMEOUT 

ETIMESTAMPMISMATCH 

E_TOO_MANY_UPDATES 

QU/pi  |Q\ 

EUNABLETOCOMPLETE 

EUNABLETOPROCEED 

EUNCOORDINATED 

SH(IS) 

EUNDEFINEDATT 

EUNRELIABLEDATA 

SH(FUR) 

EUNSOLICITED 

SH(IS) 

EUNSUPPORTEDOC 

EUNSUPPORTEDSTRAT 

SH(US) 

SH(US) 

EUNUSABLEDATA 

SH(IIR) 

EVERSION 

EZEROVALUES 
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Table  13  -  Notes  (continued) 


NOTES 

1  Use  A-U-ABORT.  Note,  however,  that  extra  elements  are  permitted  here. 

2  An  "unable-to-proceed"  error  becomes  SC(iC)  for  bind  and  N(NSO)  for  operations  if  no  DSA 
contacted  can  located  the  object. 

3  An  undefined  attributed  encountered  during  name  resolution  is  only  an  error-  N(NSO)  -  if  the  entry  is 
identified  as  local.  See  also  Note  10  below. 

4  The  A(NSA)  condition  is  reserved  in  the  case  of  "read"  for  the  situation  when  no  attribute  of  the 
specific  list  provided  can  be  returned  (for  reasons  that  include  security  errors). 

5  Any  failure  to  propagate  a  search  causes  abandonment  of  that  part  of  the  search. 

6  Undefined  attributes  are  regarded  as  not  matched  or  found,  but  cause  no  errors  in  search. 

7  This  error,  if  detected,  should  be  ignored;  processing  continues. 

8  This  error  would  occur  as  a  result  of  a  bind  argument  with  a  name  containing  too  many  RDNs  for 
the  DSA.  Use  either  S(UA)  or  S(IC). 

9  DSAs  should  use  the  time-limit  service  control  with  local  timeout  to  limit  the  remote  validation  of 
credentials;  if  the  operation  fails  as  a  result,  S(UA)  is  used. 

10  For  a  single-entry  search,  N(NSO)  may  be  used. 

1 1  Either  the  whole  attribute  should  be  removed,  or  the  deleteOldRDNflag  should  be  ignored. 

12  Wherever  S(UWP)  appears  in  the  above  tables  beside  EARGBOUNDS,  a  ROSE  "Rej"  is  also 
admissible. 

13  The  error  is  returned  when  there  are  no  partial  results,  otherwise  a  partialOutcomeQualifier  with  the 
appropriate  limitProblem  is  returned  (cf  Directory  Documents,  Part  3,  item  g  of  clause  12.8.2, and  Part 
3,  clause  10.1.3.3.1). 

14  In  every  case  where  a  security  error  occurs,  except  in  bind,  SC(NI)  may  be  used  in  place  of  the 
specified  problem,  to  support  a  Security  Policy  which  states  that  no  information  on  the  problem  may 
be  divulged.  In  the  case  of  the  bind,  SC(NI)  is  not  available. 

15  If  a  multicasting  DSA  receives  this  error  and  the  matched  part  of  the  name  is  equal  to  or  longer 
than  that  indicated  by  the  next  RDN  to  be  resolved,  name  resolution  shall  be  tai<en  as  having 
progressed.  The  error  shall  be  relayed. 

16  If  a  chaining  or  multicasting  DSA  receives  this  error  and  the  matched  part  of  the  name  is  not  equal 
to  or  longer  than  that  indicated  by  the  next  RDN  to  be  resolved,  the  error  indicates  an  incompatibility  in 
schema  between  the  DSA  and  the  one  to  which  chaining  takes  place.  Multicasting  may  continue,  and 
the  error  in  that  case  may  be  ignored.  A  DSA,  having  received  such  an  error  during  name  resoltuion, 
may  but  need  not  relay  it. 
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NOTES 

17  If  a  DSA  generates  a  chained  operation  on  the  basis  of  a  cross  reference  and  receives  a 
serviceError  with  the  problem  of  invaiidReference  in  response,  then  it  is  recommended  that  the  invalid 
cross  reference  be  removed  to  eliminate  repeated  errors.  Note  that  attempting  to  resolve  the  correct 
reference  via  the  returnCrossRefs  mechanism  should  be  regarded  as  nonreliable  due  to  the  optional 
nature  of  returnCrossRefs.  The  resolution  of  an  invaiidReference  due  to  a  superior  or  subordinate 
reference  is  a  local  administrative  issue. 


Table  14  -  Simple  credential  fields  and  protected  simple  authentication 


Simple  Credential  Field 

Equivalent  Notation  in  Directory 
Documents,  Part  8,  figure  2 

name 

A 

time1 

time2 

randomi 

random2 

password 

protected2 
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Annex  A  (normative) 
Maintenance  of  Attribute  Syntaxes 

!A.*1::  Introduction 

The  attribute  types  defined  in  the  Directory  Documents,  Part  6,  and  listed  in  table  1  have  requirements,  in 
DSAs  which  support  them,  for  underlying  algorithms  that: 

"  a)  check  attribute  values  for  syntactical  correctness  and  compliance  with  pragmatic  constraints; 

b)  match  attribute  values  (comparing  for  equality,  for  nnatching  substrings,  and  for  relative 
ordering). 

A.2     General  Rules 

A  DSA  may  receive  a  legitimately  encoded  attribute  or  AVA  that  is  unsupported  by  the  DSA.  If  the  DSA  is 
not  required  to  act  on  it,  or  to  store  it  within  an  entry,  it  may  handle  it  by  passing  it  on  without  error.  Such 
attributes  may  also  be  used  in  search  filter-item  definitions:  in  this  case,  no  error  is  reported,  but  the 
filter-item  shall  be  deemed  to  be  undefined  for  ail  entries  in  the  DSA.  This  rule  applies  to  occurrences  of 
attributes  in  both  operation  arguments  and  results. 

Conversely,  a  DSA  must  return  a  suitable  error  if  an  operation  requires  it  to  act  on  or  store  an  attribute  or 
AVA  of  type  unsupported  by  the  DSA.  This  constraint  applies  even  for  AVAs  that  are  contained  in  attributes 
that  take  names  as  values,  since  the  DSA  will  be  unable  correctly  to  match  the  attribute  values  without  this 
attribute  information, 

A.3      Checking  Algorithms 

The  subclauses  below  give  additional  checks  (beyond  those  directly  implied  by  the  Directory  Documents) 
which  shall  be  applied  to  attributes  before  they  are  stored  in  the  DSA. 

A.3.1  distlnguishedNameSyntax 

Each  component  AVA  must  be  checked,  unregistered  attribute  types  comprising  an  error;  check  also  that 
no  two  AVAs  in  the  same  RDN  have  the  same  attribute  type. 

A.3.2  integerSyntax 

Local  implementations  may  apply  local  limitations. 
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A.3.3  telephoneNumberSyntax 

The  value  of  policing  further  rules  is  for  further  study  (this  applies  also  to  telexNumber, 
teletexTerminal Identifier,  facsimileTelephoneNumber,  G3FacsimileNonBasicParameters,  x1 21  Address,  and 
iSDNAddress). 

A.3.4  countryName 

The  value  must  be  checked  for  compliance  with  ISO  3166:  1981  (E/F).  (Note  that  from  time  to  time  further 
codes  may  be  allocated.) 

A.3.5       preferred  Delivery  Method 

The  values  of  the  integer  elements  should  not  be  restricted. 

A.3.6  presentationAddress 

No  further  checks  should  be  applied. 

A.4      Matching  Algorithms 

Matching  algorithms  are  conveniently  defined  in  terms  of  a  two-step  process: 

a)  Take  the  checked  reference  value,  and  the  value  to  be  matched,  and,  if  necessary,  reduce  them 
to  a  canonical  (i.e.,  standard)  form  (normalization)  appropriate  to  each  attribute  syntax. 

b)  Carry  out  the  comparison  in  the  specified  way  (e.g.,  equality,  substrings  or  ordering)  using  the 
appropriate  rules  for  the  value  -  character  string,  integer,  boolean,  etc. 

Note  that  the  lexical  ordering  of  character  strings  (when  supported)  may  be  subject  to  local  rules. 

IMPORTANT  NOTE:  The  combination  of  normalization  and  comparison  may  be  replaced,  in  a  particular 
implementation,  by  equivalent  procedures.  Additional  notes  on  normalization  are  given  below. 

A.4.1  UTCTImeSyntax 

If  the  "seconds"  field  is  absent,  it  shall  be  inserted,  and  set  to  "00",  and  the  form  converted  to  the  "Z" 
form.Note.  The  normalization  strategy  does  not  match  times  where  the  stored  form  omits  the  seconds  field, 
and  the  compared  form  contains  it,  e.g., 

8804261 91 9Z 

8804261 91 926Z 

(It  might  have  been  expected  that  these  two  forms,which  coincide  in  time  to  within  a  few  seconds,  would 
be  considered  identical.) 
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A.4.2  dlstinguishedNameSyntax 

For  each  attribute  value,  carry  out  normalization  in  accordance  with  the  normalization  rules  defined  for  the 
type  (if  registered);  values  corresponding  to  unregistered  attribute  types  are  left  unchanged  at  this  stage. 

A.4.3  caselgnoreListSyntax 

To  facilitate  matching,  particularly  for  substrings,  normalization  may  be  considered  in  terms  of  a 
representation  which  replaces  the  separate  ASN.1  elements  by  a  single  string  with  a  delimiter. 
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Annex  B  (informative) 
Glossary 

The  following  abbreviations  may  be  useful;  not  all  are  used  within  these  agreements. 


ACL  Access  Control  List 

ACSE  Association  Control  Service  Element 

ADDMD  Administration  Directory  Management  Domain 

AETitle  Application  Entity  Title 

APDU  Application  Protocol  Data  Unit 

ASE  Application  Sen/ice  Element 

ASN.1  Abstract  Syntax  Notation  -  1 

AVA  Attribute  Value  Assertion 

BRM  Basic  Reference  Model 

CA  Certification  Authority 

CCITT  The  International  Telegraph  and  Telephone  Consultative  Committee 

CEN  Committee  for  European  Normalization 

CENELEC  Committee  for  European  Normalization  Electronique 

CEPT  Committee  of  European  Posts  and  Telephones 

COS  Corporation  for  Open  Systems 

DAP  Directory  Access  Protocol 

DIB  Directory  Information  Base 

DIT  Directory  Information  Tree 

DMD  Directory  Management  Domains 

DSA  Directory  System  Agent 

DSP  Directory  System  Protocol 

DUA  Directory  User  Agent 

EWOS  European  Workshop  for  Open  Systems 
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FT  AM  File  Transfer,  Access  &  Management 

INTAP  Interoperability  Technical  Association  for  Information  Processing,  Japan 

ISDN  Integrated  Sen/ices  Digital  Network 

ISO/I  EC  International  Organization  for  Standardization 

KT  Knowledge  Tree 

LL  Lower  layers  of  OSI  model  (layers  1  -4) 

MAP  Manufacturing  Automation  Protocol 

MHS  Message  Handling  Systems 

NIST  National  Institute  of  Standards  and  Technology 

NSAP  Networl<  Services  Access  Point 

OSI  Open  Systems  Interconnection 

PKCS  Public  Key  Crypto  System 

POSI  Promotion  for  Open  System  Interconnection 

PRDMD  Private  Directory  Management  Domain 

PSAP  Presentation  Service  Access  Point 

RDN  Relative  Distinguished  Name 

ROSE  Remote  Operations  Service  Element 

SSAP  Session  Service  Access  Point 

SIG  Special  Interest  Group 

SPAG  Standards  Promotion  &  Application  Group 

TOP  Technical  and  Office  Protocols 

TSAP  Transport  Service  Access  Point 

UL  Upper  layers  of  OSI  model  (layers  5-7) 

UPU  Universal  Postal  Union 
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Annex  C  (informative) 

Requirements  for  Distributed  Operations 

The  following  material  is  included  for  tutorial  purposes,  and  does  not  represent  material  additional  to  the 
Directory  Documents.  It  is  also  not  intended  as  a  complete  statement  of  requirements  (the  Distributed 
Operations  part  of  the  Directory  Documents  should  be  referred  to  for  a  complete  treatment). 

C.1      General  Requirements 

DSAs  supporting  distributed  operations  and  claiming  support  of  chaining  must  fully  support  DSP,  as  defined 
by  the  Directory  Documents.  DSAs  supporting  distributed  operations  must  always  be  able  to  accept 
incoming  DSP  associations  and  invocations.  DSAs  claiming  support  of  chaining  must  support: 

a)  Loop  detection 

b)  Loop  avoidance 

In  passing  on  operations  (when  chaining  or  multi-casting),  the  original  DAP-supplied  invocation  must  be 
passed  on  without  change  of  content.  In  particular,  there  must  be  no  alteration  in  anyway  of  any  primitive 
content. 

The  support  of  a  facility  for  returning  cross-references  (Directory  Documents,  Part  4,  clause  10.4.1)  is 
optional. 

To  ensure  that  tracelnformation  can  be  analyzed  properly,  DSAs  shall  only  possess  names  that  are 
compliant  with  the  recommendations  of  the  Directory  Documents,  Part  7  (including  Annex  B). 

C.2     Protocol  Support 

C.2.1       Usage  of  ChainlngArguments 

When  using  ChainlngArguments^: 

a)  originator  need  not  be  used  if  requestor  in  CommonArguments  is  used; 

b)  targetObject  shall  not  be  used  unless  the  target  object  differs  from  object/base  object  (if  it  is 
present,  object/t)ase  object  are  ignored  for  purposes  of  name  resolution); 

c)  operationProgress,  tracelnformation,  aliasDereferenced,  aliasedRDNs,  referenceType,  and 
timeLimit  shall  be  generated,  accepted,  and  used  in  accordance  with  the  Directory  Documents; 

d)  returnCrossReferences  and  info  may  optionally  be  generated,  and  shall  always  be  accepted. 


^In  this  subclause,    the  names  of  protocol   elements  (within 
ChainlngArguments)  are  italicized. 
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C.2.2       Usage  of  ChainingResults 

When  using  ChainingResults^:  crossReferences  and  info  may  optionally  be  generated,  and  shall  always  be 
accepted. 


'.(ML  'if- 


•^In  this  subclause,    the  names  of  protocol   elements  (within 
ChainingResults)   are  italicized. 
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Annex  D  (informative) 

Guidelines  for  Applications  Using  the  Directory 
D.1  Tutorial 
D.1.1  Overview 

Applications  may  have  a  requirement  for  Directory  functionality.  This  tutorial  provides  assistance  to  those 
groups  intending  to  specify  Directory  usage  for  a  specific  application  (e.g.,  Message  Handling  Systems). 

D.I. 2       Use  of  the  Directory  Schema 

D.I  .2.1        Use  of  Existing  Object  Classes 

Applications  wishing  to  use  the  Directory  should  have  determined  within  a  standard,  Implementor's 
Agreements,  or  on  a  propriety  basis,  the  relevant  Directory  schema  for  their  objects.  Consider  the  following 
two  examples: 

a)  Network  management  applications  may  with  to  define  a  SMAE  object  class; 

b)  File  transfer  applications  may  with  to  define  a  File  Store  object  class. 

Groups  should  examine  relevant  standards  to  determine  if  application-  specific  object  classes  or  attributes 
have  been  already  defined  before  considering  any  additional  definition.  These  object  classes  and  attributes 
may  be  found  in  a  variety  of  places  including  a  specific  application  standard  (e.g.,  [Recommendation  CCITT 
'88  X.402  I  ISO  10021-2]  and  the  Directory  Documents.).  Standardized  object  classes  and  attributes  should 
be  strongly  considered  before  additional  schema  elements  are  created. 

D.I  .2.2        Kinds  of  Object  Classes 

There  are  effectively  two  kinds  of  object  classes  permitted  within  the  Directory  Documents:  structural  and 
auxiliary.  The  terms  structural  and  auxiliary  are  used  here  for  convenience  when  referring  to  particular  kinds 
of  object  classes.  The  terms  themselves  are  not  defined  in  the  Directory  Documents. 

Structural  object  classes  have  associated  DIT  structure  rules  (which  control  naming).  Entries  of  this  object 
class  type  are  intended  to  be  instantiated  in  Directory  entries.  A  structural  object  class  provides  information 
on  the  base  mandatory  and  optional  content  of  a  DIT  entry. 

An  auxiliary  object  class  provides  information  to  enhance  the  mandatory  and  optional  contents  of  entries. 
It  is  always  used  in  conjunction  with  a  structural  object  class. 

The  object  class  hierarchy  is  formed  as  a  result  of  the  definition  of  structural  object  classes,  and  the  addition 
of  auxiliary  object  classes. 

For  example,  all  object  classes  in  the  Directory  Documents,  Part  7,  are  structural  except  for  strong 
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Authentication  User  and  certification  Authority.  These  two  object  classes  should  be  considered  auxiliary  and 
used  in  conjunction  with  other,  structural  object  classes. 

0.1 .2.3        Use  of  Unregistered  Object  Classes 

The  Directory  Documents,  Part  2,  clause  9.4.1  provides  a  "special"  form  of  object  class  called  "unregistered." 
An  unregistered  object  class  is  not  assigned  an  object  identifier.  One  of  the  uses  for  unregistered  object 
classes  is  to  provide  a  means  of  creating  a  single  Directory  entry  which  logically  represents  a  variety  of 
object  classes. Uses  for  unregistered  object  classes  include: 

r-c  ,.     a)  Locally  adding  attributes  to  a  predefined  superclass; 

b)  Locally  making  optional  attribute  types  in  a  predefined  superclass  mandatory; 

c)  Creating  an  object  class  derived  from  multiple  superclasses,  without  needless  proliferation  of 
registered  object  classes. 

For  example,  it  may  be  advantageous  to  provide  an  entry  which  represents  a  person  who  is  both  a  MHS 
and  a  FTAM  user. 

Unregistered  object  classes  may  best  be  illustrated  by  example.  Consider  an  entry  which  represents  a 
collection  of  company  entries  for  Fizzy  Company  whose  users  have  MHS  0/R  addresses.  Using  the 
guidelines  above,  the  Fizzy  Company  defines  an  unregistered  object  class  using  the  structural  object  class 
organizationalPerson  from  the  Directory  Documents,  Part  7,  and  the  auxiliary  object  class  mhs-user  from 
the  MHS  standards  [Recommendation  X.402  j  ISO  10021-2]  as  follows: 

f izzyCompanyPerson  ::=  OBJECT-CLASS 

SUBCLASS  OF  organizationalPerson,  mhs-user 
MUST  CONTAIN  {] 
MAY  CONTAIN  {} 

Note  that  no  object  identifier  is  assigned. 

Also  note  that  since  there  are  not  MUST  or  MAY  CONTAIN's  in  the  fizzyCompanyPerson  Object  Class,  the 
last  two  lines  of  the  object  class  assignment  (i.e.,  "MUST  CONTAIN  MAY  CONTAIN")  are  optional.  As  with 
the  registered  form  of  object  classes,  an  unregistered  object  class  always  inherits  all  the  attributes  in  any 
of  its  superclasses.  There  is  no  mechanism  defined  whereby  a  subclass  may  selectively  inherit  attributes 
from  its  superclasses. 

An  unregistered  object  class  always  appears  as  a  leaf  in  the  Object  Class  tree,  (i.e.,  An  unregistered  object 
class  may  not  be  a  superclass  of  some  other  object  class). 

Using  unregistered  object  classes  in  conjunction  with  multiple  inheritance  is  useful  as  shown  by  figure  6  in 
which  three  ways  of  creating  the  same  two  object  classes  are  shown.  Either  three,  four,  or  five  registered 
object  classes  are  used. 

Examples  (a)  and  (c)  in  figure  5  are  both  better  ways  of  defining  the  object  classes  than  that  in  example  (b), 
even  though  example  (c)  needs  to  use  one  more  registered  object  class  than  example(b).  This  is  because 
the  multiple  inheritance  technique,  used  in  examples  (a)  and  (c),  enables  a  Directory  User  searching  the 
Directory  to  easily  create  a  filter  to  find  all  entries  that  contain  mhs-user  attributes,  based  on  a  value  in  the 
object  class  attribute  (Each  Directory  entry  contains  a  list  of  the  object  identifiers  of  the  object  classes  it  has 
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inherited  from,  so  the  filter  would  just  have  to  find  all  entries  that  held  the  object  identifier  value  of  mhs-user). 
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/      \  / 
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=  person 

=  mhs-user 

=  applicationEntity 

Figure  5  -  Three  ways  of  creating  two  object  classes 


Example  (a),  which  uses  three  registered  object  classes,  is  better  than  example  (c),  which  uses  five,  because 
registering  the  extra  two  object  classes  does  not  provide  any  advantage  over  not  registering  them,  and  the 
first  method  avoids  needless  proliferation  of  registered  object  classes. 

D.1.2.4        Side  Effects  of  Creating  Unregistered  Object  Classes 

This  subclause  discusses  two  side  effects  of  creating  unregistered  object  classes. 

a)  When  an  unregistered  object  class  is  defined  from  a  single  superclass,  there  is  no  means 
available  to  distinguish  between  the  two.  Within  the  local  scope  for  which  the  unregistered  class  is 
defined,  all  relevant  entries  are  considered  to  belong  to  the  unregistered  class. 

The  following  is  an  example  of  this  problem: 

An  object  class  of  oCI  (reg)  has  attribute  type  at1  mandatory  and  at2  optional.  An  unregistered  form 
of  this,  oC1  (unreg)is  created,  which  makes  at2  mandatory.  When  an  Add  Entry  operation  is  received 
with  both  attributes  present,  the  entry  could  belong  to  either  form  of  oCl ;  it  is  indeterminate.  After 
the  entry  is  added  a  Modify  Entry  operation  is  received  which  requests  the  removal  of  attribute  type 
at2.  It  is  not  clear  if  this  operation  should  succeed,  or  whether  an  object  class  violation  should  be 
reported.  If  the  attribute  may  be  removed,  then  the  entry  belonged  to  the  oCl  (reg)  object  class  and 
the  unregistered  form  never  existed,  othen^/ise  if  the  attribute  may  not  be  removed,  then  the  entry 
belonged  to  oC1  (unreg)  and  the  registered  form  no  longer  exists. 

b)  More  than  one  unregistered  object  class  cannot  be  defined  from  the  same  superclass(es)  for 
use  within  the  same  local  scope,  as  there  is  no  means  available  to  distinguish  the  classes  from  one 
another. 

D.2     Creation  of  New  Object  Classes 

If  no  appropriate  object  class  is  available,  a  new  object  class  may  be  defined.  This  should  only  be  done  if 
no  standardized  object  classes  and  attributes  can  fulfill  the  requirements. 
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D.2.1       Creation  of  New  Subclasses 

Generally,  an  application-specific  object  class  is  defined  as  a  subclass  of  a  pre-existing  Directory  object 
class.  These  object  classes  are  specified  in  the  Directory  Documents,  Part  7.  The  subclass  nnay  be  structural 
or  auxiliary.  Optional  attributes  of  the  superclass  may  be  made  mandatory.  New  attributes  may  also  be 
added. 

For  example,  MHS  has  used  the  Directory  structural  object  class  applicationEntity  to  derive  the  object  class 
for  their  MHS-specific  application  entity  MTAs. 

If  absolutely  no  relevant  object  class  is  available,  an  object  class  may  be  defined  as  a  subclass  of  the  basic 
object  class  called  'Top." 

If  no  appropriate  object  class  is  available,  a  new  object  class  may  be  defined.  This  should  only  be 
undertaken  If  no  standardized  object  class  can  fulfill  the  requirements.  When  defining  new  object  classes 
the  object-class  macro,  as  defined  in  the  Directory  Documents,  Part  2,  clause  9.4.6,  should  be  used. 

If  new  subclasses  are  defined,  suggested  or  required  name  forms  may  also  be  specified  in  text. 

D.2.2       Creation  of  New  Attributes 

If  no  appropriate  attributes  are  available,  a  new  attribute  type  may  be  defined.  This  should  only  be 
undertaken  if  no  standardized  attributes  can  fulfill  the  requirements.  When  defining  new  attributes  the 
attribute  macro,  as  defined  in  the  Directory  Documents,  Part  2,  clause  9.5.3,  should  be  used. 

D.3      DIT  Structure  Rules 

Applications  may  desire  to  provide  guidance  on  DIT  structure  rules  and  naming.  As  with  object  classes, 
standardized  or  suggested  structure  (including  naming)  rules  from  the  Directory  Documents  part  7,  Annex 
B  and  application-specific  standards  should  be  consulted  before  providing  new  structure  rules.  Annex  B  in 
the  Directory  Documents,  Part  7,  provides  guidelines  on  how  to  specify  this  information.  Structure  rules 
associated  with  superclasses  should  be  adopted  wherever  suitable. 
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Annex  E  (informative) 

Template  for  an  Application  Specific  Profile  for  Use  of  the  Directory 

The  template  defined  below  should  be  used  by  OIW  SIGs  intending  to  specify  Directory  usage.  Such 
application  specific  profiles  shall  be  contained  in  application  specific  chapters  of  the  OIW  agreements.  The 
information  under  each  heading  should  be  filled  in  (the  text  under  each  heading  provides  guidance  on  the 
meaning  of  the  heading  and  should  not  be  included  in  the  profile). 

a)  PROFILE  TITLE 

Application  specific  profiles  are  named  in  the  following  way: 

OIW  <SIG-NAME>  < DESCRIPTOR >  DIRECTORY  PROFILE 

(e.g..  OIW  DIRECTORY  STRONG  AUTHENTICATION  DIRECTORY  PROFILE  ) 

b)  OTHER  PROFILES  SUPPORTED 

Other  OIW  Directory  profiles  which  are  to  be  used  by  this  specific  application  are  listed  here. 
Attributes,  attribute  sets,  object  classes  and  structure  rules  that  are  referenced  in  these  profiles  need 
not  be  enumerated  below. 

c)  STANDARD  APPLICATION  SPECIFIC  ATTRIBUTES  AND  ATTRIBUTE  SETS 

Any  attributes  supported  from  the  relevant  standards.  For  example,  the  MHS  SIG  might  include 
mhs-or-address  here. 

d)  STANDARD  APPLICATION  SPECIFIC  OBJECT  CLASSES 

Any  object  classes  supported  from  the  relevant  standards.  For  example,  the  MHS  SIG  might  include 
mhs-user  here. 

e)  OIW  APPLICATION  SPECIFIC  ATTRIBUTES  AND  ATTRIBUTE  SETS 

This,  optional,  component  of  this  profile  allows  for  the  specification  of  OIW  application  specific 
attributes  and  attribute  sets.  This  section  of  this  template  should  be  used  rarely  and  with 
consideration  that  no  standard  profile  or  attribute/attribute  set  exists  which  can  be  used. 

f)  OIW  APPLICATION  SPECIFIC  OBJECT  CLASSES 

This,  optional,  component  of  this  profile  allows  for  the  specification  of  OIW  application  specific 
object  classes.  This  section  of  this  template  should  be  used  rarely  and  with  consideration  that  no 
standard  profile  or  object  class  exists  which  can  be  used. 

g)  STRUCTURE  RULES 

Guidance  for  DIT  structural  rules,  provided  only  when  structure  rules  associated  with  superclasses 
are  not  adopted.  The  Directory  Documents,  Part  7,  Annex  B  provide  an  example  and  guideline  to 
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